Just wait until they go on vacation. When they get back, tell them it was a
hurricane.

Better luck with your next experiment :-)

Joseph wrote:

If you have an old DOS PC laying around, you may like to use my FREEWARE
application that allows using up to twenty DS18S20 temperature sensors:

http://www.geocities.com/kiwi_36_nz/tlog/mlog.htm

Regards, Kiwi Geoff.

Thanks for the link. It looks like a very nice, simple and inexpensive way
to do things. However, I think the other unit will suit me better, as I can
plug it into the serial port of an existing WinXP PC and read the temps as
ASCII data. The smarts are already on the board.

----- Original Message -----
From: "Geoff" geoff36@gmail.com
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Sent: Sunday, July 24, 2005 9:20
Subject: Re: [time-nuts] Temperature measurements

At 8:46 PM -0600 7/24/05, Joseph Gray wrote:

Joseph,

I had the joy of measuring the temperature of a big spectrometer
system over the last 6 months to learn about its instabilities. I
used self-adhesive chip RTD sensors from Minco feeding a National
Instruments FieldPoint box. My experiences led me to the following:

1. The temperature of the equipment tends to be similar to its
   performance instabilities, but the time lag of the electronics is
   widely dependent on the airflow and mounting of the circuitry. I saw
   time lags of anywhere from 5 seconds to an hour in different parts of
   my spectrometer.

2. You may learn lots of interesting things about your air
   conditioning system. In my case, I learned that the building chiller
   system runs 24 hours a day, but the office heater coils were shut off
   from 11PM to 6AM (presumably to save power). This provided some nice
   temperature step functions to evaluate the time lags of the various
   electronics boxes.

3. The mounting of sensors with regard to time lag is only important
   if the circuitry is forced-air cooled. The time lag of the stuff in
   the box will be longer than that of the sensor if there's no air
   passing through. Room air is best measured at the air inlet to one of
   your electronics boxes.

4. To achieve decent stability of some moderately power-hungry
   electronics on the order of a minute, I had to modify the forced-air
   cooling to isolate room air from the air inside the box. This is
   perhaps not interesting to you, but it's very useful to know if you
   have circuit boards that dissipate a fair amount of heat yet need to
   be temperature-stabilized.

5. Outside air is best measured with a sensor glued to a small sheet
   of aluminum that's shielded from the sun yet has ready access to
   airflow. The size of the sheet determines the time lag of the sensor.
   Alternately, a small sensor with a ~1 second time lag may be hung in
   the air by its leads. Last year I built a gadget to measure
   atmospheric turbulence for telescope seeing, using micro
   thermocouples suspended in air. It had a couple hundred Hertz
   frequency response. Two of the sensors were destroyed in a rainstorm,
   at $40 each for repair.

--

--David Forbes, Tucson, AZ
http://www.cathodecorner.com/

In message 035b01c590c3$193567c0$66fea8c0@antecp4, "Joseph Gray" writes:

I use Maxim 1-wire sensors, they're very simple to workt with.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

From: "Joseph Gray" jgray@zianet.com
Subject: Re: [time-nuts] Note on physical stabilities of timing equipment
Date: Sun, 24 Jul 2005 20:35:50 -0600
Message-ID: 035701c590c1$9231c3f0$66fea8c0@antecp4

Out on luck there, we are fresh out of hurricanes you see. ;O)

Thanks!

I will do that during the next hurricane-free period, which has been going for
quite a while now... ;O)

Cheers,
Magnus

In message 039201c59100$dbbea8a0$66fea8c0@antecp4, "Joseph Gray" writes:

Then you can't measure it, and it is even tricky to do so with fancy
hardware.

The problem is pretty deep once you start to think about it:  the
computers notion of time is tied to an internal counter and unless
you can eletrically get hold of that counter and measure that relative
to some external reference, you have no idea how close the CPU's
concept of time is the the real UTC/TAI time.

Once you have measured that, measuring the DTR pin relative to
the same external reference is trivial and then your answer is
a simple subtraction.

You can see some discussion about this problem in my timecounter
paper: http://phk.freebsd.dk/pubs/timecounter.pdf

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

From: "Joseph Gray" jgray@zianet.com
Subject: [time-nuts] Agilent appnote
Date: Mon, 25 Jul 2005 01:46:35 -0600
Message-ID: 037401c590ec$fba12210$66fea8c0@antecp4

Joseph,

Sadly, I don't have that App-note, however...

May I propose that you take a sufficiently low frequency (100 kHz may suffice)
squarewave, split it so that you trigger START (directly, put the splitter on
the start BNC) and then the other output of the splitter goes to the cable
which connects to the STOP channel. Measure and preferably integrate over some
100 measurements at least.

That is at least what I would assume that 174-10 says:

The 100 kHz squarewave has a cycle of 10 us, so it should suffice for a cable
length of about 10000 [ns] * 2/3 * 0.3 [m/ns] = 2000 [m] = 2 km. A 1 MHz would
handle cables up to 200 m, a 5 MHz up to 40 m and then naturally a 10 MHz up to
20 m, so it all depends on your cable length. If one run with a too high
frequency, one has the electrical length modulo cycletime, but if you handle
that ambiguity it will work just as well.

There is a number of error-sources in the method (different delays down the
legs of the power-splitter, different trigger positions, different waveshapes
to trigger due to slope differences etc.) so if you really care you need to
take compensation actions (measuring rise-times and compensate difference for
instance).

The resolution for this measurement is limited by the counters time resolution.
However, if you are using the same counter for measuring the cable as you do
for the actual measurements, the time-resolution is relatively on par with
each other (depending on the detailed measurement setup) so it should be fairly
OK.

If you have access to a high speed TDR, then measure first the time to the
adapter (just leave it open), then hook on the cable and leave end open and
measure the time to the now delayed reflection. Half the time difference is the
electrical length of the cable. Unfortunatly high speed TDRs isn't lying around
as they should do, it is a good tool.

Cheers,
Magnus

Joseph Gray wrote:

Sorry I can't help directly but do have some suggestions

1. I have set up a web page where people can request application notes, manuals, help etc they want on
   test equipment, hoping others will provide a copy (legally of course). In the case of an Agilent
   application note like that, I would stick it on my web site, as I do have permission from Agilent to
   do so.

I only 'finished' this web page at 2am local time this morning, so there are going to be buge. I would
appreciate any comments. It ia also my first attempt at a semi large perl program. I've always seemed
to avoid learning perl, but realised it was almost essential in the end. #!/bin/sh does have its limits.

I would appreciate some feedback -  if people think this is useful, what catagoies of test equipment
should be added, any spelling mistakes etc etc. See it at

http://www.drkirkby.co.uk/community/test-equipment/

Feel free to put in any silly entries (to test it), or a serious entry if you want to use it properly.
Once I get some feedback, I'll remove the silly entries and leave the serious requests. Then I will
announce the page a bit more widely, with the hope others will add their resources.

Here are a couple of suggestions of how you might measure cable lenght.

1. Buy a Vector Network Analyser with S-parameter test set - an expensive option.

2. If you have a time interval counter, measuring absolute phase delay at a frequency within the TI
   counter's range, would not be hard. Just measure time, and compute length knowing frequency.

Unless you do it with sexless connectors (APC7 or similar), or your cable has opposite sex connectors
on its ends, you are going to need an adapter that you remove to replace with the cable.

So you are really measuring cable_length-adapter_length. The electrical length of the adapter could be
estimated with a high degree of accuracy with a ruler amd knowing the diectric constant (its usually
PTFE). I suspect (but have not thought about it too much) you could measure the length of the adapter
by making multiple measurements at different

Comparing the length of two cables is even easier, as you don't need to know the length of an adapter.

A vector network analyser would be the best way of course, but you are more likely to have a TI counter.

3. Another option would be a directional coupler and TI counter. Feed the ouput of a sig gen into the
   start input of a TI counter, and put it in the input port of a directional coupler. Put the reflected
   power from the coupler into the stop input. There will be a high reflection, as the output of the
   coupler is unterminated. Now add your cable, and again there will be a large reflection, but this time
   it would be delayed by twice the cable length.

This method, is basically what is used in the calibration procedure of vector network analysers.
Application notes on their theory should be on the Agilent web site.

--
Dr. David Kirkby PhD CEng MIEE,
Senior Research Fellow,
Department of Medical Physics,
Mallet Place Engineering Building,
Gower St,
University College London,
London WC1E 6BT.

In message 20050725.124305.26278789.cfmd@bredband.net, Magnus Danielson writes:

Normally this is done with a network analyzer by measuring the phase difference
at two different frequencies and calculating which delay would cause that.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Joseph Gray wrote:

As a sensor, the AD592AN, BN or CN are quite nice. They give a constant current, proportial to
absolute temperaature (1 uA/K) it does not matter how long the leads are. But due to their packaging,
the thermal time constant is not goingt be very short. (You can always average data later to get a
slower response, so it is worth having a fast response and filtering later if needed).

Here's some data I collected with the TI counter working in its normal mode - not loopback. It looks OK.
http://www.g8wrb.org.uk/useful-stuff/time/data/abrupt-changes-in-TI/foo.jpg
That was done with a themmistor.

Here is some in loopback mode (look at the bottom two graphs).
http://www.g8wrb.org.uk/useful-stuff/time/data/abrupt-changes-in-TI/temp-data.html
There you can see a problem which seems to be correlated with temperature. Taking it out of its
loopback mode seems to clear that.

I took all of that data with a thermistor at the input air vent of the TI counter. As doors are
opened, so the temperature changes rapidly, which seems to cause problems with the TI counter in
loopback mode.

If you want fast response, I would think a thermistor is probably the best bet, as they are very small
and easy to use. A thermocouple would have a faster response, but they are not quite as easy to use.

I don't think covering the leads of a small thermistor in expoxy should not significantly change its
time constant. You can get them hemetically sealed quite easily.

Dr. David Kirkby PhD CEng MIEE,
Senior Research Fellow,
Department of Medical Physics,
Mallet Place Engineering Building,
Gower St,
University College London,
London WC1E 6BT.

From: "Poul-Henning Kamp" phk@phk.freebsd.dk
Subject: Re: [time-nuts] Agilent appnote
Date: Mon, 25 Jul 2005 12:53:27 +0200
Message-ID: 71765.1122288807@phk.freebsd.dk

That is two methods yes (you need to distinguish between phase-delay and
group-delay). However, considering that he was reading AP200-3 the text giving
the reference is:

+/- Systematic Error

[...]

In most measurement situations, the use of equal length cables cancels out
this error [the difference between start and stop channel cable delay];
however, cable delay varies with the dielectric constant of the insulation so
cables of the same kind should be used. Where this is not practical, the
electrical lengths of the cables can be measured by the counter to determine a
correct factor to apply to the counter reading. Application Note 174-10,
Measuring Electrical Length (Delay) of Cables, discusses this measurement in
detail.

[...]

So, if you read the second sentence carefully, you see that they are saying
that you can measure this delay with your counter and then in the following
sentence they point out that AP174-10 details on how to make such a
measurement. So, in this case I think the network analyser is out of the
picture. This is why I gave the counter based hint, because I do beleive this
is more or less what is happening in AP174-10. Also, when doing this measure
one is measuring more or less under the same conditions as the system is to be
used. If you use a network analyser you might need to spend some more time than
you anticipate to come up with the correct value, since that is really a
frequency-wise measure and the counter is doing time-wise measures, so you
should do an inverse Fourier transform if you want to do it properly, so it
gets a bit messy.

As a side-note, some of the systematic errors in the measurement methods I
gave will cancel (and some will partially cancel) when calculating the delay
difference which is to be used for start-stop correction.

Cheers,
Magnus

Magnus, your psychic ability is amazing :-) Yes, I was reading AP200-3. I'm
surprised that I can't find AP174-10 at Agilent, though.

Thanks to everyone for the helpful suggestions. I had actually done a simple
measurement of a cable with my 5370A. I saw this method mentioned on John
Ackerman's site. The results I came up with were a bit longer than the
actual cable. I wasn't sure if this was due to the BNC connectors and tee
adapter, or some error in my measurement.

Here is what I got with the average of 100 measurements: Mean = 19.197 nS

I calculated the mean value times C (299,792,458 m/S) and then by the
velocity factor (Beldin RG-58AU is .66, right?). This comes out to 12.47 ft.
The coax I was using is 12 ft long.

As for the phantom appnote, I would still like to see a copy. It may provide
further insight into the process.

You may have a "bias" error.  Try connecting 1 PPS to the start input
and stop input via equal length of  bnc barrels or  two very short
pieces of matched length cable.  Run your measurements again - you mave
have to subtract the "bias" from your measurements to get a true reading.

Bria - N4FMN

Joseph Gray wrote:

From: "Joseph Gray" jgray@zianet.com
Subject: Re: [time-nuts] Agilent appnote
Date: Mon, 25 Jul 2005 10:42:05 -0600
Message-ID: 03c301c59137$ca9d1c50$66fea8c0@antecp4

Joseph,

Not really, I can be really friendly to a Google in a window near me, and since
that appnote was being discussed recently putting one and one together was not
that difficult. ;O)

I'm doing a general digging around for HP/Agilent appnotes right now...
Let's see what pops up.

With those values the k-value should be .6355 which certainly is possible, but
a small time-offset would certainly skew values downwards:

 l

k = ---
t*c

Belden RG-58A/U 50 Ohm is 0.66 (where as the 52 Ohm is 0.73 and 53.5 Ohm is
0.75, all is "RG58A/U"), so doing it backwards to get the time we would expect
a delay of 18,485 ns, so you have some 711 ps extra. That is 140 mm and I don't
think that is all measurement error, but some I would expect to be in stuff
like additional lag etc. However, the speed in cable may very well be lower.
Also, do you really have exactly 12 feet of cable?

I agree.

Cheers,
Magnus

Also... it might seem obvious, but check your 5370's reference levels to
make sure they're both 0.00.  I don't remember which button calls up those
settings to the display, but if they don't match exactly (and/or your 5370
is not in calibration), the Start and Stop channels will trigger at
different phases of the signal.

Is this genuine Belden cable, or whatever was on sale at Radio Shack last
week?  It does make a difference. :)

-- john, KE5FX