Re: [time-nuts] Why using HP5370 ext-ref is (maybe) a bad idea
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. Bob On Mar 3, 2014, at 2:26 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message e7a494f6-78f1-4568-8bd3-d94a32deb...@rtty.us, Bob Camp writes: Do you have any idea how 'clean' your 200 MHz signal is? The manual suggests getting it to -65 dbc for subs using a spectrum analyzer. That's pretty far down. I seem to recall the adjustment process being a bit tedious (lots of back and forth). My estimate is that all harmonics are at least -50 and most probably -60 down. The 10MHz is probably the worst. My Lab is not really set up for RF work, so this is probably an area where one of the hams could do lot more competent job than me. I've attached a plot of one of the runs yesterday, beause things are more complicated than I initially thought. The vertical bars are AVG +/- STDDEV of 1000 sample TI on a 10MHz from my HP3336 in start-com mode. The X-axis is the phase offset set on the HP3336 in degrees, and represents the phase difference between the ext-ref and start+stop signals on the HP5370 plus some arbitrary offset due to cables etc. Obviously, the phase difference has no systematic meaning for the red bars, since it is free running on the OCXO at some frequency offset from the input signal. Yet, it is quite evident that there still is a periodicity in the data, which peaks around 0, 5, 10 and 15 degrees. The green bars however... The initial artifact I noticed when I just plotted the STDDEV is still there, around 9 degrees where both the average and the stddev take a hop. But that blib is peanuts relative to the 3-degree periodicity for which I have absolutely no explanation, and the equally evident 18-degree periodicity. The 3-degree periodicity cannot be a simple harmonic, it it were it would be a 1.2 GHz signal. (360/3 * 10 MHz = 1200 MHz) But what then ? As in a canonical scientific paper, I have to conclude that more research is clearly needed, and I'd really love to see what results other people might get. In the meantime, run you 5370 on internal clock, and rely on the law of big numbers. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. intext.png ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message c542adee-19dd-4dab-a1bf-fb842c077...@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 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
What about replacing the 3336 external reference with something like an HP 10811 and checking what difference, if any, that makes? Regards Nigel GM8PZR In a message dated 03/03/2014 13:42:33 GMT Standard Time, p...@phk.freebsd.dk writes: In message c542adee-19dd-4dab-a1bf-fb842c077...@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 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message 834d5.64e2b237.4045e...@aol.com, gandal...@aol.com writes: What about replacing the 3336 external reference with something like an HP 10811 and checking what difference, if any, that makes? The internal reference is an 10811 already ? The point is not what delivers the reference, but if it is synchronized to the input signals being measured. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
Sorry, I must have missunderstood. I realise the internal reference is already a 10811, but I thought there was some concern that just the use of the external reference facility might be in some way responsible, so if that was the case then perhaps using an external 10811 might also be expected to cause the same problem?. If it did then that would potentially rules out any issues with the 3336. Regards Nigel GM8PZR In a message dated 03/03/2014 14:12:38 GMT Standard Time, p...@phk.freebsd.dk writes: In message 834d5.64e2b237.4045e...@aol.com, gandal...@aol.com writes: What about replacing the 3336 external reference with something like an HP 10811 and checking what difference, if any, that makes? The internal reference is an 10811 already ? The point is not what delivers the reference, but if it is synchronized to the input signals being measured. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message 107931.7dbf8887.4045e...@aol.com, gandal...@aol.com writes: I realise the internal reference is already a 10811, but I thought there was some concern that just the use of the external reference facility might be in some way responsible, [...] No, I see no signs of that anywhere in my experiments. The issue is if the HP5370 internal signals are synchronized to the signals you're trying to measure, then you're in trouble. I saw the same kind of phenomena running the HP5370 on its internal OCXO and feeding the HP3336 ref-in from HP5370-ref-out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
Uncorrelated noise improves resolution in certain systems, even mechanical ones... it´s called dither: http://en.wikipedia.org/wiki/Dither Daniel Em 03/03/2014 11:35, Poul-Henning Kamp escreveu: In message 107931.7dbf8887.4045e...@aol.com, gandal...@aol.com writes: I realise the internal reference is already a 10811, but I thought there was some concern that just the use of the external reference facility might be in some way responsible, [...] No, I see no signs of that anywhere in my experiments. The issue is if the HP5370 internal signals are synchronized to the signals you're trying to measure, then you're in trouble. I saw the same kind of phenomena running the HP5370 on its internal OCXO and feeding the HP3336 ref-in from HP5370-ref-out. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
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 ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
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 ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
Hi Poul-Henning, On 03/03/14 14:41, Poul-Henning Kamp wrote: In message c542adee-19dd-4dab-a1bf-fb842c077...@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 ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
On 03/03/14 16:16, Daniel Mendes wrote: Uncorrelated noise improves resolution in certain systems, even mechanical ones... it´s called dither: http://en.wikipedia.org/wiki/Dither ... as used in the HP5328A with option 40. Got it. :) PS. Still wish I had the GPIB for it. 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message 5314e957.30...@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 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message 5314ef87.1020...@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 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
On 03/03/14 22:35, Poul-Henning Kamp wrote: In message 5314ef87.1020...@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 ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message 531505bc.4050...@rubidium.dyndns.org, Magnus Danielson writes: On 03/03/14 22:35, Poul-Henning Kamp wrote: In message 5314ef87.1020...@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 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
On 03/03/14 23:59, Poul-Henning Kamp wrote: In message 531505bc.4050...@rubidium.dyndns.org, Magnus Danielson writes: On 03/03/14 22:35, Poul-Henning Kamp wrote: In message 5314ef87.1020...@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 ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
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. 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. 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. Looking at some old notes from years past which just didn't make sense, does now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
Hi Do you have any idea how “clean” your 200 MHz signal is? The manual suggests getting it to -65 dbc for subs using a spectrum analyzer. That’s pretty far down. I seem to recall the adjustment process being a bit tedious (lots of back and forth). Bob On Mar 2, 2014, at 5:29 PM, Poul-Henning Kamp p...@phk.freebsd.dk 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. 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. 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. Looking at some old notes from years past which just didn't make sense, does now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message e7a494f6-78f1-4568-8bd3-d94a32deb...@rtty.us, Bob Camp writes: Do you have any idea how 'clean' your 200 MHz signal is? The manual suggests getting it to -65 dbc for subs using a spectrum analyzer. That's pretty far down. I seem to recall the adjustment process being a bit tedious (lots of back and forth). My estimate is that all harmonics are at least -50 and most probably -60 down. The 10MHz is probably the worst. My Lab is not really set up for RF work, so this is probably an area where one of the hams could do lot more competent job than me. I've attached a plot of one of the runs yesterday, beause things are more complicated than I initially thought. The vertical bars are AVG +/- STDDEV of 1000 sample TI on a 10MHz from my HP3336 in start-com mode. The X-axis is the phase offset set on the HP3336 in degrees, and represents the phase difference between the ext-ref and start+stop signals on the HP5370 plus some arbitrary offset due to cables etc. Obviously, the phase difference has no systematic meaning for the red bars, since it is free running on the OCXO at some frequency offset from the input signal. Yet, it is quite evident that there still is a periodicity in the data, which peaks around 0, 5, 10 and 15 degrees. The green bars however... The initial artifact I noticed when I just plotted the STDDEV is still there, around 9 degrees where both the average and the stddev take a hop. But that blib is peanuts relative to the 3-degree periodicity for which I have absolutely no explanation, and the equally evident 18-degree periodicity. The 3-degree periodicity cannot be a simple harmonic, it it were it would be a 1.2 GHz signal. (360/3 * 10 MHz = 1200 MHz) But what then ? As in a canonical scientific paper, I have to conclude that more research is clearly needed, and I'd really love to see what results other people might get. In the meantime, run you 5370 on internal clock, and rely on the law of big numbers. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. attachment: intext.png___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
On 01/03/14 01:47, Bob Camp wrote: Hi There is a fairly involved alignment process for the multiplier chain. My *guess* is that small tweaks to the alignment could impact these timing spikes. Sub harmonics tend to produce multiple zero crossings that show up as periodic jitter in the output. The offset input peaks may be a better thing to look at as you tweak the multiplier than the “official” adjustment procedure. It was exactly what I was hinting about, it may be a better procedure as it addresses the actual precision rather than indirect phase noise measures. Just doing phase-noise measures rather than spectrum analysis helped to illustrate the problem. 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] Why using HP5370 ext-ref is (maybe) a bad idea
Instead of using the external reference input, any thoughts on actually disciplining the internal OCXO to bypass the problem? -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
On Mar 2, 2014, at 6:20 AM, Brian Lloyd br...@lloyd.com wrote: Instead of using the external reference input, any thoughts on actually disciplining the internal OCXO to bypass the problem? I almost put a GPS front-end chip and small FPGA on the 5370 board. You can imagine where that idea was going. I mean, you've got that whole BeagleBone just sitting there with some spare cycles now that I use the PRU. But it would have doubled the BOM cost. Probably more depending on the choice of DAC solution. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
Idea. On the next go around for the board put the copper down and holes for a couple small daughter cards and any support logic needed to interface with the BBB. The the only additional cost would be limited to the daughter board I/O since my guess it would be SMT hence a bit hard to leave it unpopulated. -pete On Sat, Mar 1, 2014 at 9:39 AM, John Seamons j...@jks.com wrote: On Mar 2, 2014, at 6:20 AM, Brian Lloyd br...@lloyd.com wrote: Instead of using the external reference input, any thoughts on actually disciplining the internal OCXO to bypass the problem? I almost put a GPS front-end chip and small FPGA on the 5370 board. You can imagine where that idea was going. I mean, you've got that whole BeagleBone just sitting there with some spare cycles now that I use the PRU. But it would have doubled the BOM cost. Probably more depending on the choice of DAC solution. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
On 01/03/14 18:20, Brian Lloyd wrote: Instead of using the external reference input, any thoughts on actually disciplining the internal OCXO to bypass the problem? Considering that it's a HP10811A, it shouln't be too hard. In general, doing a new A8 board might be an option. 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] Why using HP5370 ext-ref is (maybe) a bad idea
On Mar 2, 2014, at 7:05 AM, Pete Lancashire p...@petelancashire.com wrote:
Idea. On the next go around for the board put the copper down and holes for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.
Good idea. Also the Beagle spec allows for multiple, stacked interface boards
('capes' they call them). So for a backwards compatible solution an
experimental GPSDO + backup power cape could be interposed between the Beagle
and 5370 board. I say experimental because I have no idea if any of the SDGPS
projects out there would be ultimately suitable for a DO.
This brings up a question I have about how the PPS edge is actually derived by
a GPS receiver. Does it originally come from the NAV data stream and then get
corrected by the (fixed-mode) positioning solution to account for
transmission/system delays? I know about the issue of alignment with the VCTCXO
clock, but I'm talking about upstream of that.
___
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] Why using HP5370 ext-ref is (maybe) a bad idea
Hi
They run an NCO (drop / add pulses) to generate the PPS off of the TCXO. The
amount of adjustment is a function of the solution they derive from the GPS
messages. In some cases they do a solution, and correct the *next* edge to that
solution. In other chip sets the solution and the edge come out at the same
time.
Bob
On Mar 1, 2014, at 2:02 PM, John Seamons j...@jks.com wrote:
On Mar 2, 2014, at 7:05 AM, Pete Lancashire p...@petelancashire.com wrote:
Idea. On the next go around for the board put the copper down and holes for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.
Good idea. Also the Beagle spec allows for multiple, stacked interface boards
('capes' they call them). So for a backwards compatible solution an
experimental GPSDO + backup power cape could be interposed between the Beagle
and 5370 board. I say experimental because I have no idea if any of the SDGPS
projects out there would be ultimately suitable for a DO.
This brings up a question I have about how the PPS edge is actually derived
by a GPS receiver. Does it originally come from the NAV data stream and then
get corrected by the (fixed-mode) positioning solution to account for
transmission/system delays? I know about the issue of alignment with the
VCTCXO clock, but I'm talking about upstream of that.
___
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] Why using HP5370 ext-ref is (maybe) a bad idea
In message CAE3hgTd5UDz_-T5mvgBarYYyuLwn=+00p1fho2fs+t1p1xd...@mail.gmail.com , Brian Lloyd writes: Instead of using the external reference input, any thoughts on actually disciplining the internal OCXO to bypass the problem? The end result would be no different than using ext-ref. Right now I think the best approach to smear the error out, is to run ext-ref from a frequency which is well-known, but not synchronous with the input signals, for instance from a synth like the 3336 or a carefully mis-tuned GPSDO The EFC pin on the OCXO in the 5370 is grounded in a way that makes it quite hard to unground. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
not being able to get to my two dead 5370Bs is there enough clearance to
allow for stacking capes ? If not the interface could be a 'horizontal'
implementation. Another one that just came to mind is have holes that
would allow one to put a metal can over the digital blocks / capes /
boards. Holes would go to ground.
On Sat, Mar 1, 2014 at 11:02 AM, John Seamons j...@jks.com wrote:
On Mar 2, 2014, at 7:05 AM, Pete Lancashire p...@petelancashire.com
wrote:
Idea. On the next go around for the board put the copper down and holes
for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.
Good idea. Also the Beagle spec allows for multiple, stacked interface
boards ('capes' they call them). So for a backwards compatible solution an
experimental GPSDO + backup power cape could be interposed between the
Beagle and 5370 board. I say experimental because I have no idea if any of
the SDGPS projects out there would be ultimately suitable for a DO.
This brings up a question I have about how the PPS edge is actually
derived by a GPS receiver. Does it originally come from the NAV data stream
and then get corrected by the (fixed-mode) positioning solution to account
for transmission/system delays? I know about the issue of alignment with
the VCTCXO clock, but I'm talking about upstream of that.
___
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] Why using HP5370 ext-ref is (maybe) a bad idea
Hi,
Internally you typically run a 1 ms frame on everything. You integrate a
cycle of C/A code on each channel, sample state on all channels with the
1 ms clock and the solution will disclose the time-error of that 1 ms
clock so knowing how a 1 PPS relates to the 1 ms clock is fairly
trivial. The resolution will naturally be that of the core-clock, and
ones the delay for the right 1 ms frame has been setup, the PPS error
compared to the solution is known and you can calculate the sawtooth
if you care about it.
PPS as such is not in the GPS signal, rather all the time-info you need
to create it.
Cheers,
Magnus
On 01/03/14 20:06, Bob Camp wrote:
Hi
They run an NCO (drop / add pulses) to generate the PPS off of the TCXO. The
amount of adjustment is a function of the solution they derive from the GPS
messages. In some cases they do a solution, and correct the *next* edge to that
solution. In other chip sets the solution and the edge come out at the same
time.
Bob
On Mar 1, 2014, at 2:02 PM, John Seamons j...@jks.com wrote:
On Mar 2, 2014, at 7:05 AM, Pete Lancashire p...@petelancashire.com wrote:
Idea. On the next go around for the board put the copper down and holes for
a couple small daughter cards and any support logic needed to interface
with the BBB.
The the only additional cost would be limited to the daughter board I/O
since my guess it would be SMT hence a bit hard to leave it unpopulated.
Good idea. Also the Beagle spec allows for multiple, stacked interface boards
('capes' they call them). So for a backwards compatible solution an
experimental GPSDO + backup power cape could be interposed between the Beagle
and 5370 board. I say experimental because I have no idea if any of the SDGPS
projects out there would be ultimately suitable for a DO.
This brings up a question I have about how the PPS edge is actually derived by
a GPS receiver. Does it originally come from the NAV data stream and then get
corrected by the (fixed-mode) positioning solution to account for
transmission/system delays? I know about the issue of alignment with the VCTCXO
clock, but I'm talking about upstream of that.
___
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] Why using HP5370 ext-ref is (maybe) a bad idea
On 01/03/14 22:38, Poul-Henning Kamp wrote: In message CAE3hgTd5UDz_-T5mvgBarYYyuLwn=+00p1fho2fs+t1p1xd...@mail.gmail.com , Brian Lloyd writes: Instead of using the external reference input, any thoughts on actually disciplining the internal OCXO to bypass the problem? The end result would be no different than using ext-ref. Right now I think the best approach to smear the error out, is to run ext-ref from a frequency which is well-known, but not synchronous with the input signals, for instance from a synth like the 3336 or a carefully mis-tuned GPSDO Would work if integer cycles is covered over the measurement time such that samples is taken spread over the 100 ns reference cycle. The EFC pin on the OCXO in the 5370 is grounded in a way that makes it quite hard to unground. Kapton tape into the connector, a wire soldered to EFC on the 10811? 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] Why using HP5370 ext-ref is (maybe) a bad idea
On 28/02/14 22:51, Poul-Henning Kamp wrote: A long time ago, I found out that the HP5370 is quite sensitive to qualities of the external reference signal and after playing around with it a bit, I decided to run my HP5370 from its own OCXO since that was both reproducible and eliminated what I suspected was the root cause. While playing around with John's new CPU board, and now having a bit more kit in my lab, I decided to revisit this detail. The setup I created is the following: 10 MHz GPS locked lab-standard feeds ext-ref on the HP3336. The HP3336 generates 10MHz/0dBm which feeds ext-ref on the HP5370 The same lab-standard also feeds the start input of the HP5370 which is setup to start-common, TI, 1k samples, output stddev. And then I step the phase of the HP3336 generated 10MHz through 0...360 degrees relative to the lab-standard. The result is the attached plot, where for every 18 degrees the stddev increases by 8-10ps, roughly 40%. This is evidently because the ext-ref on the HP5370 is multiplied to 200MHz, which is what drives the counter circuits. Another way to run this experiment, is to set the HP3336 to 10.001 MHz and log the stddev's over time while the two clocks sweep each other by in phase. Doing it this way can give you a plot of much higher resolution. And that scenario is where the trouble starts: If the HP5370 ref-in clock synchronous to the experimental signals, you will most likely be lucky, but sometimes you will not and the noise will be much larger. If the HP5370 ref is not synchronous, for instance running of its own OCXO, the two phases will sometimes conspire briefly and you get a few noisy samples, but the average will almost always be good. I have not tried to calibrate/trim the HP5370 to see what that does to these spikes, but it would be an interesting experiment. I'm not a bit surprised. I tried using the normal HP5370 trimming routines, but I found that using my SIA3000 helped a lot on the 200 MHz synthesis chain. Also, as I have told before the board doing the 10 MHz logic spews out a lot of 5 MHz with overtones, which is a simple mod away. Would be interesting to see if you could trim these systematics down by tweaking the syntesis chain. Maybe some peaks is good indicators for a particular stage offset, which would be expected from the x5 followed by x4 multipliers with tons of filters. The 50 MHz tank would be a good prime suspect I would think. 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] Why using HP5370 ext-ref is (maybe) a bad idea
In message 53110bc6.6010...@rubidium.dyndns.org, Magnus Danielson writes: Also, as I have told before the board doing the 10 MHz logic spews out a lot of 5 MHz with overtones, which is a simple mod away. I remember you mentioning this, but I never did the mod on my counter, got anything I can search for in the mail-archive ? Would be interesting to see if you could trim these systematics down by tweaking the syntesis chain. It is not obvious to me that the 200MHz multiplier is involved in its own capacity, it may simply be that the 200MHz is slewed across the input signal and that the zero-crossing jitter therefore moves into the window where it matters ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ 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] Why using HP5370 ext-ref is (maybe) a bad idea
On 01/03/14 00:06, Poul-Henning Kamp wrote: In message 53110bc6.6010...@rubidium.dyndns.org, Magnus Danielson writes: Also, as I have told before the board doing the 10 MHz logic spews out a lot of 5 MHz with overtones, which is a simple mod away. I remember you mentioning this, but I never did the mod on my counter, got anything I can search for in the mail-archive ? Not from the top of my head. What I did was that I soldered one of the transistors base to ground (if I recall correctly) so that the comparator got stuck in the state. Fairly straight-forward. Look at the A8 board and the Q8 and Q6. That ECL loop requires the 10 MHz to be reasonably running for the LED to go on. Don't need that when not looking or suspecting problems. ECL having good rise-time creates shit-load of overtones. Would be interesting to see if you could trim these systematics down by tweaking the syntesis chain. It is not obvious to me that the 200MHz multiplier is involved in its own capacity, it may simply be that the 200MHz is slewed across the input signal and that the zero-crossing jitter therefore moves into the window where it matters ? It does not have to be the 200 MHz syntesis, but it can be. The 10 MHz banks at the 50 MHz resonator tank every 50 ns through the transistor, and if de-tuned will the transitions be of the mark the further you go. The same thing for the 200 MHz resonator tank. The filters helps to other frequencies out. The resonator tanks is just re-triggered oscillators which have saw-tooth time-error phase which you can trim down by moving them more onto frequency. Then again, 200 MHz may cross-talk into the signal path and modulate the trigger point. My guess is both happen to a degree. 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] Why using HP5370 ext-ref is (maybe) a bad idea
Hi There is a fairly involved alignment process for the multiplier chain. My *guess* is that small tweaks to the alignment could impact these timing spikes. Sub harmonics tend to produce multiple zero crossings that show up as periodic jitter in the output. The offset input peaks may be a better thing to look at as you tweak the multiplier than the “official” adjustment procedure. Bob On Feb 28, 2014, at 7:07 PM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 01/03/14 00:06, Poul-Henning Kamp wrote: In message 53110bc6.6010...@rubidium.dyndns.org, Magnus Danielson writes: Also, as I have told before the board doing the 10 MHz logic spews out a lot of 5 MHz with overtones, which is a simple mod away. I remember you mentioning this, but I never did the mod on my counter, got anything I can search for in the mail-archive ? Not from the top of my head. What I did was that I soldered one of the transistors base to ground (if I recall correctly) so that the comparator got stuck in the state. Fairly straight-forward. Look at the A8 board and the Q8 and Q6. That ECL loop requires the 10 MHz to be reasonably running for the LED to go on. Don't need that when not looking or suspecting problems. ECL having good rise-time creates shit-load of overtones. Would be interesting to see if you could trim these systematics down by tweaking the syntesis chain. It is not obvious to me that the 200MHz multiplier is involved in its own capacity, it may simply be that the 200MHz is slewed across the input signal and that the zero-crossing jitter therefore moves into the window where it matters ? It does not have to be the 200 MHz syntesis, but it can be. The 10 MHz banks at the 50 MHz resonator tank every 50 ns through the transistor, and if de-tuned will the transitions be of the mark the further you go. The same thing for the 200 MHz resonator tank. The filters helps to other frequencies out. The resonator tanks is just re-triggered oscillators which have saw-tooth time-error phase which you can trim down by moving them more onto frequency. Then again, 200 MHz may cross-talk into the signal path and modulate the trigger point. My guess is both happen to a degree. 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. ___ 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.
