Why using HP5370 ext-ref is (maybe) a bad idea
In message C542ADEE-19DD-4DAB-A1BF-FB842C0775FB@rtty.us, Bob Camp writes:
The likely answer is that the trigger point must be changing.
Yes that would be my first theory as well.
The question is whether it's changing because the
3336 is doing something (small waveform changes) or because the 5370 is
doing something.
Yes, and obviously there are many experiments that can be performed
to flesh out the details of that:
Changing the 3336 output amplitude.
Exchanging the signals, so the 3336 feeds ext-ref,
and lab-standard feeds start+stop.
Using a different lab-standard.
Measuring opposite polarity etc.
I would make up / dig up a coax cable that is 8 degrees at 10 MHz.
Something around 1/2 meter long should do the job.
As I said, I'm not really kitted out for RF work, so my selection
of coax isn't that versatile and I don't have the crimp-tools or
routine to make my own.
Next step would be some sort of filtering between the 3336 and the 5370.
That would help rule out harmonics and spurs from the generator as the
source of the problem.
The 3336 delivers pretty clean output, so I expect a couple of sanity
checks will exonerate it.
Unfortunately my HP33120 does not have an external clock input, so I
can't use that for the experiment. Anybody with a HP3325 or later
HP33* with an external clock input can participate in this game...
But to be honest, I'm not sure how much more work is really warranted
for me, given that I don't think I can tune the 200MHz multipliers
filters much better than they presently are.
The really interesting experiments, in my mind, would be to ditch the
200MHz multiplier and feed 200MHz from a good generator with high
purity instead.
But then again: It is so much easier to just run the HP5370 on the
internal clock and that solve^H^H^H^H^Hhides all the problems.
--
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.
Hi Poul-Henning,
On 02/03/14 23:29, Poul-Henning Kamp wrote:
I have spent another evening playing around with the 5370 and the
conclusion is pretty ironclad now:
Running a 5370 with ext-ref locked to input frequencies is simply
a bad idea and should not be done.
Running it on the internal OCXO works fine.
Running it on another frequency not locked to the input frequenc
also works fine.
In both cases the errors are statistically well-behaved, and can
be treated with normal statistical methods, including the built-in
STD-DEV function.
But feeding ext-ref a frequency which is locked to the input frequencies
causes the errors to become systematic, and they can no longer be
treated as statistically well-behaved.
This comes as no surprise to me. I've expected this to be true for
essentially all counters for ages. The relative timing of reference and
trigger inputs interact with each others.
Running one of the input synchronous to the reference may not only
create a maximum but also a minimum in noise. When inputs is
asynchronous it is the average of this systematic pattern which is
experienced.
For instance: The length of the coax to ext-ref suddenly affect
your TI measurements, because it shifts the phase between the 200MHz
and the input signal.
I tried tuning up the A21 200MHz synthesizer to the best of my
ability, and it clearly made a difference, the phase pattern
of errors shifted around, but the errors did not get any smaller,
they just moved.
Which then gives support to your theory that it is the 200 MHz itself
rather than systematics of the synthesizer as I was theorizing about.
Thus, as you tune the synthesizer you only phase-shift around the
transitions. OK. Fair enough, that is expected to happen too.
The synthesizer probably needs to be very badly trimmed to cause
systematics as I theorized.
I also tried disconnecting the "10 MHz present" circuit, that
didn't change the magnitude of the errors either, but did shift
the phase of the peak noise a couple of degrees.
I used it to clean of the 5 MHz overtones and systematics.
Looking at some old notes from years past which just didn't make
sense, does now.
Good that things becomes clearer.
Cheers,
Magnus
On 03/03/14 14:14, Bob Camp wrote:
Hi
IF I understand the plot (and that’s a big if, it’s early and I’ve had limited coffee): The period is shifting with phase. We trust the 3336 to be on frequency. The likely answer is that the trigger point must be changing. The question is whether it’s changing because the 3336 is doing something (small waveform changes) or because the 5370 is doing something.
I would make up / dig up a coax cable that is 8 degrees at 10 MHz. Something around 1/2 meter long should do the job. If you see the same period shift when you use it, the problem is more likely in the 5370 than in the 3336.
Next step would be some sort of filtering between the 3336 and the 5370. That would help rule out harmonics and spurs from the generator as the source of the problem. I’d try a lowpass filter first since I have them in my junk box. My junk box and yours may not be stocked with the same stuff :)
My only concern is that we spend time chasing 5370 issues and not subtle gotcha’s with the signal source. I’m looking for some quick / easy / cheap ways to narrow things down. If you have a toggle switch based line stretcher, by all means use it instead of making up a cable.
Well, considering that you make 6 cycles in 18 degrees of the 10 MHz,
this means that you have 6*20=120 cycles over 10 MHz or 1,2 GHz.
Another approach would be to consider it as the 6th overtone of the 200
MHz signal.
Poul-Henning, you sure have given us something to think about! :)
YES! :)
I think I will have to figure out how to duplicate your measurement.
Realize that I need to work on getting some GPIB programming done so I
can get some scripts going.
Cheers,
Magnus
Hi Poul-Henning,
On 03/03/14 14:41, Poul-Henning Kamp wrote:
In message C542ADEE-19DD-4DAB-A1BF-FB842C0775FB@rtty.us, Bob Camp writes:
The likely answer is that the trigger point must be changing.
Yes that would be my first theory as well.
Cross-talk and ground-bounce through common inductor is known to cause
this issue. Seems to recall that Bruce mentioned such a note on the
5370, which I think I have lying around here somewhere.
I know that one vendor found out that putting input channel comparators
in separate ICs reduced ground-bounce through power-leads between
signals. A big issue as you try to get further down the precision scale.
The question is whether it's changing because the
3336 is doing something (small waveform changes) or because the 5370 is
doing something.
Yes, and obviously there are many experiments that can be performed
to flesh out the details of that:
Changing the 3336 output amplitude.
Exchanging the signals, so the 3336 feeds ext-ref,
and lab-standard feeds start+stop.
Using a different lab-standard.
Measuring opposite polarity etc.
All good ideas. I have some more below.
I would make up / dig up a coax cable that is 8 degrees at 10 MHz.
Something around 1/2 meter long should do the job.
As I said, I'm not really kitted out for RF work, so my selection
of coax isn't that versatile and I don't have the crimp-tools or
routine to make my own.
Next step would be some sort of filtering between the 3336 and the 5370.
That would help rule out harmonics and spurs from the generator as the
source of the problem.
The 3336 delivers pretty clean output, so I expect a couple of sanity
checks will exonerate it.
Unfortunately my HP33120 does not have an external clock input, so I
can't use that for the experiment. Anybody with a HP3325 or later
HP33* with an external clock input can participate in this game...
Got a HP3325B, HP5370B/C/D but also 5359A and SR535.
Another approach is to set a rubidium for a slow scan over
phase-relationships.
But to be honest, I'm not sure how much more work is really warranted
for me, given that I don't think I can tune the 200MHz multipliers
filters much better than they presently are.
If that is where the issue is.
The really interesting experiments, in my mind, would be to ditch the
200MHz multiplier and feed 200MHz from a good generator with high
purity instead.
Those with a high quality RF generator could force-feed a 200 MHz into
the counter and see if it makes any major difference.
BTW, have someone looked at how the 200 MHz is then used? Sure that no
"interesting" interaction happens there?
But then again: It is so much easier to just run the HP5370 on the
internal clock and that solve^H^H^H^H^Hhides all the problems.
Yes, but Poul-Henning, we are time-nuts, we dive deep just for the fun
of it, to see what we can learn. :D
Cheers,
Magnus
In message 5314E957.30703@rubidium.dyndns.org, Magnus Danielson writes:
Realize that I need to work on getting some GPIB programming done so I
can get some scripts going.
I've mentioned it before, but I'll plug it again:
https://github.com/bsdphk/pylt
The script I used for the plots I sent look like this:
#!/usr/bin/env python
from __future__ import print_function
import time
import socket
import hp3336c
# Use TCP/IP to Johns ARM board
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("hp5370", 5370))
s.send("ST9\r\n")
s.send("MD2\r\n")
s.send("SS3\r\n")
# Purge whatever is buffered
s.settimeout(1)
while True:
try:
x = s.recv(40)
except socket.timeout:
break
print(x)
s.settimeout(None)
g = hp3336c.hp3336c()
print("ID", g.id)
# Setup frequency and amplitude manually, this only reports...
print("Freq: %.11e Hz %.1f dBm" % (g.read_freq(), g.read_dbm()))
fo = open("/tmp/_q", "w")
ph = 0
for m in range(180):
ph += 1
g.wr("PH%.1fDE" % (.1*ph))
time.sleep(.1)
s.send("\n")
data = s.recv(80).strip()
data += " | " + s.recv(80).strip()
print("%4d" % m, "%5.1f" % (.1 * ph), data)
fo.write("%4d " % ph + "%5.3f " % (.1 * ph + j * .005) + data + "\n")
--
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.
In message 5314EF87.1020204@rubidium.dyndns.org, Magnus Danielson writes:
Got a HP3325B, HP5370B/C/D but also 5359A and SR535.
Another approach is to set a rubidium for a slow scan over
phase-relationships.
Hmm, I have a 5359A as well, I din't consider that as a possible
input source.
Detuning a Rb is obviously feasible, but being able to key in the
phase you want on 0.1deg units is so much more convenient and
repeatable.
But to be honest, I'm not sure how much more work is really warranted
for me, given that I don't think I can tune the 200MHz multipliers
filters much better than they presently are.
If that is where the issue is.
Well, seeing how the pattern changed after I tuned A21, I'm pretty
certain that a lot of issues are there, but maybe not all.
It would be really interesting if the plot can be displayed in
something approaching real time, so it would become feasible to try
to tune A21 based on this plot, rather than a spectrum analyzer.
Havn't quite figured out how to do that, but using Fast Binary
mode on the 5370 and a 10,000,000.1 Hz signal from the HP3336
should be able to do it in half a second...
The one sensible idea I have on the 1.2GHz is that it comes from
the BBB. A run with the original CPU can resolve that.
Absent that the "1.2GHz" signal simply doesn't make any sense, there
are no frequencies that high in the 5370 anywere, it must be aliasing
of a subharmonic somewhere.
Those with a high quality RF generator could force-feed a 200 MHz into
the counter and see if it makes any major difference.
Yes, that would be an interesting experiment.
BTW, have someone looked at how the 200 MHz is then used? Sure that no
"interesting" interaction happens there?
It's squared up to ECL and fed to the digital side of things.
If anybody have a capable HP82xx that might also be an option.
But then again: It is so much easier to just run the HP5370 on the
internal clock and that solve^H^H^H^H^Hhides all the problems.
Yes, but Poul-Henning, we are time-nuts, we dive deep just for the fun
of it, to see what we can learn. :D
Yes, but there is so much to learn, and so little time...
--
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.
On 03/03/14 22:35, Poul-Henning Kamp wrote:
In message 5314EF87.1020204@rubidium.dyndns.org, Magnus Danielson writes:
Got a HP3325B, HP5370B/C/D but also 5359A and SR535.
Another approach is to set a rubidium for a slow scan over
phase-relationships.
Hmm, I have a 5359A as well, I din't consider that as a possible
input source.
What you want is a synchronous trigger and means to steer the relative
timing with sufficient precision. The 5359A and SR535 is there for
exactly this type of exercise with their 50 ps and 5 ps step size.
I'm only fear they might have too much noise, but I need to check that.
Detuning a Rb is obviously feasible, but being able to key in the
phase you want on 0.1deg units is so much more convenient and
repeatable.
Agreed. Just wanted to widen the scope of feasible solutions for setting
up alternative solutions such that a multitude of approaches could get
similar enough results.
But to be honest, I'm not sure how much more work is really warranted
for me, given that I don't think I can tune the 200MHz multipliers
filters much better than they presently are.
If that is where the issue is.
Well, seeing how the pattern changed after I tuned A21, I'm pretty
certain that a lot of issues are there, but maybe not all.
It would be really interesting if the plot can be displayed in
something approaching real time, so it would become feasible to try
to tune A21 based on this plot, rather than a spectrum analyzer.
Which was what I was proposing earlier. One idea would be to dial in a
suitable phase-relationship and then tune until the value goes "better"
on the display and then tune to another phase-relationship. This assumes
you just don't shift it around, but can actually work on it to become
better.
Havn't quite figured out how to do that, but using Fast Binary
mode on the 5370 and a 10,000,000.1 Hz signal from the HP3336
should be able to do it in half a second...
The one sensible idea I have on the 1.2GHz is that it comes from
the BBB. A run with the original CPU can resolve that.
Absent that the "1.2GHz" signal simply doesn't make any sense, there
are no frequencies that high in the 5370 anywere, it must be aliasing
of a subharmonic somewhere.
Indeed. Let's assume that it's not the BBB causing the issue, but it's
inherent to the 5370 design.
Did you know that the 200 MHz meets the trigger levels on the A18 board?
That's where the DAC for trigger levels of the START and STOP channels
is located, as well as coarse counting for N0 occurs. The 200 MHz is fed
into a tunable filter, and then into U15 MC10216 which is acting as a
three-stage amplifier. Now, there's a high-slew-rate source of 200 MHz
at the source-end of the trigger levels. There's filtering through a
pi-filter as distributed between the A18 board (10 nF to ground, 680 nH
in series) and A3 board (10 nF to ground, via resistor).
Would be interesting to "sniff" near those to see if the 200 MHz creeps
into the trigger that way. It would sure explain a lot.
Those with a high quality RF generator could force-feed a 200 MHz into
the counter and see if it makes any major difference.
Yes, that would be an interesting experiment.
It's a bit problematic thought, the signal is fed to three different
places, A19, A20 (the interpolators) and A22.
BTW, have someone looked at how the 200 MHz is then used? Sure that no
"interesting" interaction happens there?
It's squared up to ECL and fed to the digital side of things.
"digital" if I may. In these cases, "digital" is but a side-case of
analogue. :)
If anybody have a capable HP82xx that might also be an option.
I'll see how "clean" the 200 MHz is on my SIA.
But then again: It is so much easier to just run the HP5370 on the
internal clock and that solve^H^H^H^H^Hhides all the problems.
Yes, but Poul-Henning, we are time-nuts, we dive deep just for the fun
of it, to see what we can learn. :D
Yes, but there is so much to learn, and so little time...
That's why we hunt together and learn from each other.
Cheers,
Magnus
In message 531505BC.4050900@rubidium.dyndns.org, Magnus Danielson writes:
On 03/03/14 22:35, Poul-Henning Kamp wrote:
In message 5314EF87.1020204@rubidium.dyndns.org, Magnus Danielson writes:
Indeed. Let's assume that it's not the BBB causing the issue, but it's
inherent to the 5370 design.
Charles reminded me of this document in private email:
http://www.ko4bb.com/Manuals/06)_App_Notes_-_Proceedings/HP_5370/HP5370-DNL-Mod.pdf
It explicitly mentions the 5370A, so I guess a check is in order
if the ...B has these changes already.
Those with a high quality RF generator could force-feed a 200 MHz into
the counter and see if it makes any major difference.
Yes, that would be an interesting experiment.
It's a bit problematic thought, the signal is fed to three different
places, A19, A20 (the interpolators) and A22.
I would go for TP1 at A21 ?
--
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.
On 03/03/14 23:59, Poul-Henning Kamp wrote:
In message 531505BC.4050900@rubidium.dyndns.org, Magnus Danielson writes:
On 03/03/14 22:35, Poul-Henning Kamp wrote:
In message 5314EF87.1020204@rubidium.dyndns.org, Magnus Danielson writes:
Indeed. Let's assume that it's not the BBB causing the issue, but it's
inherent to the 5370 design.
Charles reminded me of this document in private email:
http://www.ko4bb.com/Manuals/06)_App_Notes_-_Proceedings/HP_5370/HP5370-DNL-Mod.pdf
It explicitly mentions the 5370A, so I guess a check is in order
if the ...B has these changes already.
That's the one I mentioned earlier. I also recall it was fixed in the B.
Those with a high quality RF generator could force-feed a 200 MHz into
the counter and see if it makes any major difference.
Yes, that would be an interesting experiment.
It's a bit problematic thought, the signal is fed to three different
places, A19, A20 (the interpolators) and A22.
I would go for TP1 at A21 ?
Well, either you lift R1 and insert the signal into that one, or you
lift C15 and insert signal there... and use that amplifier chain.
Just inserting on TP1 isn't very smart, even if you unplug the 10 MHz
input to the multiplier chain.
Think I will sniff with the near-field probe tomorrow.
Cheers,
Magnus