Adev and standard used in measurements of it. - Page 1
Forum section: electronics / general

author: tkamiya
author_rank: Super Contributor
timestamp: January 16, 2020, 07:30:18 pm
content: Firstly, I wanted to thank everyone in contribution to my Rb and GPSDO thread. I wanted to ask this question but in a new thread, as it really is a different topic. It will kind of show how newbie I am but so be it. I need to know.Adev -Allen Deviation. There is an X axis which is time, which is TAU. This is a measuring period, correct? So If I see the graph at 100s is 1E-12, it basically is saying if I average or keep the gate open for 100 second and measure the DUT with my counter, there is 1E-12 uncertainty.Standard -I have various standards. Double Oven Xtal Oscillator, GPSDO, Rubidium, and Cesium. Which one to use for what measurement is a big mystery to me. I know each one has strength and weaknesses, like GPSDO is good for long measurement and not so with short. Can someone please give me examples? Does this mean, if I use GPSDO in adev measurement, Tau reading of 1000s is likely to be more accurate but such of 10s is not to be trusted in equal? Where does Rb fit in?Thank you.

author: 5065AGuru
author_rank: Frequent Contributor
timestamp: January 17, 2020, 01:53:26 am
content: tkamiya,Hi. I will give you some details on my AD measurements that should help.My references are:For Taus of greater than 10 Sec and up to 1000 Sec or so I use my HP5065A.For greater than 1000 Sec I use the KVARTZ passive MaserFor less than 10 Sec I use a selected FTS 1200 OCXOSee the plots in this post-https://www.eevblog.com/forum/metrology/really-old-hp5065a-on-ebay-right-now!/msg2751920/#msg2751920The FTS 1200 is not shown but is around 3 to 4 X10-13th at the low Taus.Also note the spec for an FE5680 Rubidium.If you test your Quartz units against each other you can get an idea of how good a reference they are.Quartz (good ones!!!) will easily beat Rubidium and Cesium in the short term.A 10811-60109 will usually run around 5 to 8 X10-13th up to 100 Sec!Frequently I will plot a unit against the 5065A and then against the FTS1200.Then combine the plots with the lower Tau readings from the 1200 and the higher Tau from the 5065A.If you look thru this documenthttp://leapsecond.com/corby/Super-5065A-Project.pdfyou will notice that the plots have two color segments. These are the 1200 and Maser combined.Hope this helps??Cheers,Corby

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 02:11:32 am
content: Corby,Yes, I read about you using more than one reference for one plot and merging the result. That's a great idea but I lack the kind of reference comparable to yours.If you'd allow me, I'd like to ask more basic question. This is a question on Adev itself. To plot any point at tau of 100s, data was take was either an average of 100 seconds worth of data or gate time of 100s (thus becoming an average) and that is averaged multiple times?That would mean to get a really accurate and precise plot, you need all 3 and switch at intervals you indicated?Actually, I have purchased several OCXO and they have been waiting for me to put them into service.I'm in the middle of "the great reference" project where I take a PRS-10 and steer it with Tbolt. The results are quite unexpected. That lead me to think, maybe my understanding of how to read adev maybe incorrect. I'm getting great help from members of the forum. But I wanted to be perfectly certain my understanding of adev itself is correct. I've read many MANY literature but none of them describe it in layman's term.Oh, what fun!

author: KE5FX
author_rank: Super Contributor
timestamp: January 17, 2020, 02:38:31 am
content: Quote from: tkamiya on January 17, 2020, 02:11:32 amTry the chapter in the TimeLab manual entitled "What's all this ADEV stuff, anyhow?" (Page 41 of the current version.)Straightforward ADEV measurements don't use averaging at all, just one-shot measurements of phase differences or gap-free measurements of frequency differences. The result when averaging is present is more akin to MDEV.

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 03:13:00 am
content: But doesn't that conflict with the statement on the same page, line "Why did my plot stop at 1000 seconds? It took an hour to run"?For example, I have 2 day measurement run going at this very moment. When my measurement started, Adev was reading E-15 range, which I knew it was not possible. 1s measurement kept on moving at seem to stop at near E-15. But over 6 hours of run so far, it gradually moved up and stopped at more reasonable 2xE-12.Seems to me (and it's probably wrong) 1 time measurement that is displayed at 1s and already its place plotted, is being influenced by ones done over the last 6 hours. Why is this, and then, why does it take so long? (the original question).

author: 5065AGuru
author_rank: Frequent Contributor
timestamp: January 17, 2020, 05:07:08 am
content: tkamiya,My DMTD system is usually setup with a 1Hz offset generator.This gives me phase data at a 1Hz rate.You would like to take your data for 10X the maximum Tau you want to accurately plot.For instance if you want to know the AD at 100Sec you would need to take the data for 1000Sec.A plot using this 1000Sec run would give you results from 1Sec to 100Sec.The plot might show data at Taus higher than 100Sec but that data is not reliable.There is something wrong with your setup if you are reading in the -15 range!Try taking data for 100 Sec and then 1000 Sec.The 1 Sec Tau AD should be comparable for both plots.Cheers,Corby

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 05:43:45 am
content: Yes, I know. Something is VERY wrong with something in my setup. There is no way my PRS10 can approach anywhere near 10^-15 range.I'm looking at such a graph right now. It is now at 4 hour mark and the graph is now reaching 2000s. ONE second is reading 10^-15. What will happen in next few hours is, 1s to 100s will slowly move up, and it will land somewhere near 10^-12.As to my setup, 10MHz from GPSDO is fed into HP53132A as reference. It is reading PRS10's 10MHz output. The counter is talking to TimeLab via serial line and it is measuring frequency, not time interval. Gate time is set to one second, so I can get full 12 digits.I was actually watching while it went to 10s then to 100s. 1s reading moved wildly to 10s. Between 10s to 100s, 1s reading slowly moved up. I also have confidence bar displaying. It is so narrow, it is invisible at 1 to 10s. But I know it will move up to -12 to -13 range.It is not making any sense to me.

author: KE5FX
author_rank: Super Contributor
timestamp: January 17, 2020, 06:35:18 am
content: Quote from: tkamiya on January 17, 2020, 05:43:45 amPost a screencap of your acquisition dialog? It should look something like this:Also, look at the frequency readings on the counter itself. Do they make sense?

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 03:27:15 pm
content: Here is mine. I'm doing this via serial port, and talk-only-device.On graph, Blue line represents 10MHz out from PRS-10. Reference is GPS.Magenta line represents from 10MHz out from PRS-10, reference is GPS, and PRS-10 PPSIN is connected to GPS (same one) ppsout.Readings were taken separately, one at a time.Last night, 6 hours into measurement, blue line was between 1E-14 and 1E-15.

author: 5065AGuru
author_rank: Frequent Contributor
timestamp: January 17, 2020, 04:46:21 pm
content: Still have a problem with your setup!The blue line slope is wrong, the magenta lines slope is OK but no way should you be reading parts in 10-14 at 100 Sec!Does your 53132A have the high stability reference?If so try a run without the GPS input to the external reference.Also you might want to try setting up and use time interval mode on the counter.Run with the counters internal ref., feed 1PPS from GPS and PRS10 into the start and stop inputs, set triggering do get valid counts and then do a data run.Change from frequency to phase difference in your setup.Cheers,CorbyCheers,Corby

author: thinkfat
author_rank: Unknown
timestamp: January 17, 2020, 04:58:23 pm
content: I'm guessing you have a scaling error somewhere. Are you sure about what Timelab receives from the counter? Is it frequency in Hz? Or is it scaled to something else?

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 05:56:57 pm
content: Corby,I will be happy to trade my PRS10 with your Hydrogen Maser....Yes, it has high stability option. I'm doing that now. (by the way, now, the graph starts from 1E-16 range)Taka

author: 5065AGuru
author_rank: Frequent Contributor
timestamp: January 17, 2020, 06:24:37 pm
content: After re-reading your notes I see that the magenta trace is what I call a baseline trace and represents your measurement noise floor.This since you are using the GPS as both inputs.So you magenta trace looks good as the parts in 10-14th is the floor not an actual measurement.Not sure why it does not continue to drop?Try running with the 10Mhs PRS10 into the counter reference and also as the input.This should look like the magenta plot but hopefully continue to drop and will give you a look at the AD floor your equipment can provide.Cheers,Corby

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 06:41:37 pm
content: Actually no.Magenta plot represents GPS 1 pps going to PRS10, GPS 10MHz going to counter as reference, and PRS10 10Mhz going to counter as DUT. So it is not a base line plot. PRS10 is in the middle for one leg and straight in for another.But, it is now obvious that there is something awfully wrong with my setup. I am thinking taking GPS+PRS10 setup completely out of the equation and evaluate the measuring system by itself. I also have an HP5071A. It has much better resolution than 53132A in interval counter mode. (100ns vs 20ns) I might use that.Yes, I will try the baseline measurement as you suggest.

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 07:21:20 pm
content: I found something weird.I take a measurement, save the TIM file and re-trigger it with another measurement. In Previous post, I said, with internal clock, it is showing 1E16 area? It redrew it as 1E-6 going down to 1E-9 in almost straight line. In fact, when I stop the measurement, it redraws and it redraws differently sometimes.Currently running a reference plot. Started at 2E-16 and up until leading end of the graph was -100s, it was going down in wavy fashion. Now it is at 300 second, it is GOING UP! Counter is reading 999..... to 100.... at all times.WEIRD!

author: tkamiya
author_rank: Super Contributor
timestamp: January 17, 2020, 08:09:58 pm
content: Here's the reference plot of my HP53132A. 10MHz from PRS10 fed to both reference and input.Both images are from same measurement. Light blue plot represents the plot in question. Still in frequency mode. Please note, first, it was down, then it's going up. Brown line is actually a same precision. I just saved it earlier. See, the slop and well established part moves?Red line is with internal oscillator measuring rubidium output. Odd thing was, earlier in plot, it was in E-16 range.Just so that it is clear, I am not suggesting there is something wrong with TimeLab. It is likely something I'm doing. I just want to figure this out.

author: KE5FX
author_rank: Super Contributor
timestamp: January 18, 2020, 01:08:03 am
content: Hmm, OK, so you're running in talk-only mode, not with the actual 53132A driver. You may need to select 'HP 53131A / 53132A mode' to avoid getting bad data (is there a reason why you haven't selected it?), but since I don't own one of those counters, I'm not 100% sure when that's really necessary. It was inherited from some code by Tom Van Baak.Stick with frequency count mode (since it's easier to set up than TI mode) but maybe try the dedicated 53132A acquisition driver.Also, you may want to look at the 'f'requency difference view to see how the data looks. Until you're sure that the frequency readings are coming across OK, there's little point in worrying about the ADEV plot.

author: tkamiya
author_rank: Super Contributor
timestamp: January 18, 2020, 01:38:42 am
content: 53132A mode, I read in manual, is to ignore statistic output it can spit out. Since I don't get that, (it has to be setup in 53132A) I didn't select it. I used talk only because I had it connected via serial port. The actual driver, as I understand, is for GPIB. Just few days ago, I did setup GPIB so I can use it that way, too. Manual says to use talk-only mode when going through serial port.Frequency difference mode has very weird look. I don't understand this at all. Everything is at bottom of the screen. But on right, it's showing 10.xxxxx Hz. 10 POINT?Now, I go to acquisition screen. Incoming data is showing "9.9999999 MHz. Legend says Frequency (Hz) Input frequency is set to 10000000 Hz (10MHz) Looks like there is a confusion between MHz and Hz. Can this be causing this weirdness? Will you please look at this screen in fine tooth comb mode and advise? I think Numeric Field # field is set incorrectly?For your reference, here's the matching graph and setup.

author: iMo
author_rank: Super Contributor
timestamp: January 18, 2020, 01:57:07 am
content: "9.999999999999 MHz" is not correct afaik.That is 9.99Hz for TimeLab.It has to be 9.99999999999e6TimeLab parses only numbers and ignores other strings.

author: tkamiya
author_rank: Super Contributor
timestamp: January 18, 2020, 02:04:35 am
content: SUCCESS! Either that or something close to what it should be.I set the numeric format to 1 x 1e6Please see the green line.Here's the result.Now, what I am not sure is.... data goes between 9.9999.... to 10.00000.... In other words, the place of decimal point changes. How do I handle that...?

author: iMo
author_rank: Super Contributor
timestamp: January 18, 2020, 02:09:05 am
content: Let it be.

author: tkamiya
author_rank: Super Contributor
timestamp: January 18, 2020, 02:10:17 am
content: Beatles?

author: tkamiya
author_rank: Super Contributor
timestamp: January 18, 2020, 02:16:57 am
content: I just went to Frequency difference plot. I can verify 9.999.... and 10.000.... are parsed correctly.

author: KE5FX
author_rank: Super Contributor
timestamp: January 18, 2020, 02:38:54 am
content: Yep, that makes sense. If the counter is sending values in MHz, they will need to be rescaled to Hz. It's helpful to examine the data coming across with the 'Monitor' button before beginning the acquisition, when in doubt.Using the counter as a talk-only device via its serial port is a good way to go. Saves a lot of potential glitches, since the communication process between the counter and TimeLab only has to work in one direction.

author: tkamiya
author_rank: Super Contributor
timestamp: January 18, 2020, 02:48:40 am
content: Thanks for your help and everyone else's. Someone suggested multiplication factor, too. I reviewed it but missed this entirely. I am going to let this run, RUN for 2 days and good base line measurement for my HP53132A. It is a straight line (after a while) of slope of -y like expected. Yaaaaay!Few days ago, I got Prologix GPIB to work with this setup. I've been working on some kind of adapter to talk forever. Agilent kind was a copy and didn't work well. National Instrument, I still haven't tried. Prologix was easy.Question... What does TimeLab send to devices? Does this mean counter setup is automatically done when I set up acquisition dialog?

author: KE5FX
author_rank: Super Contributor
timestamp: January 18, 2020, 03:15:21 am
content: Quote from: tkamiya on January 18, 2020, 02:48:40 amVery little. It relies on you to set up the measurement manually, then fetches individual readings. You can see the different instructions sent to various counters including the 53131/53132 if you look at the makefile in the drivers\GPIB_TIC subdirectory:This is why I usually suggest using talk-only mode when possible. That leaveseverythingup to the operator to set up, resulting in less room for confusion.

author: tkamiya
author_rank: Super Contributor
timestamp: January 18, 2020, 10:33:02 pm
content: I see. I would imagine with number of counters in the market, it would be impossible to send commands for setup.....One of the issues I experienced in the past with talk-only setting is, some counters can readings out of order. TICC is a good example of this. I know there are walk-around for this but unexpected outcome can happen. I had a lengthy email conversation with TICC developers and apparently, it cannot be helped.Right now, I have 17 serial ports setup on my PC, and all ports are taken. It comes in very handy for use with TimeLab and LadyHeather.

author: tkamiya
author_rank: Super Contributor
timestamp: January 19, 2020, 07:02:04 pm
content: The measurement has few hours to go.Again, I have a stable 10MHz from Rubidium fed to both counters input and external reference. Gate time 1s, full 12 digit mode. Measurement is frequency.As I watched the counter, it mostly stayed at 9.999..... occasionally showing 10.000... I didn't think anything of it as last digit on any counter is always iffy by a count or two. Then I looked at frequency graphs on TimeLab. It's actually centered on -1.00E-11 with almost equal jump up and down by one count. (-2.00E-11 to 0.00E-12) Why is this? Since the signal was tee'd off to both, it should center on exactly the 10MHz, doesn't it?Shouldn't reference = DUT = 10MHz?

author: jpb
author_rank: Super Contributor
timestamp: January 19, 2020, 09:49:01 pm
content: The ADEV noise floor looks too low to me.Given that the resolution of the 53132A is 150 psecs I'd expect a noise floor at 1 second of around 10^-10. My FCA3100 has a resolution of 50psecs and has a noise floor (back-to-back measurements) or around 5 x 10^-11.Are you sure that the measurements are each separate (it is not acquiring a running average of some sort)?I don't think that the 53132A can do back-to-back measurements, and I don't think it does time-stamping which would allow for some linear regression though neither of these is the issue here.

author: tkamiya
author_rank: Super Contributor
timestamp: January 19, 2020, 11:13:10 pm
content: I do believe 53132A's internal interpolation mechanism does use some kind of running total or averaging. I did not intentionally turn on anything. It is at default state other than gate time. Other than that, I'm not sure of anything. In fact, how unsure I am is the topic of this thread.Either that or I have a super deluxe version option 999 on my counter.

author: tkamiya
author_rank: Super Contributor
timestamp: January 20, 2020, 02:15:33 am
content: OK, 2 day run is complete! Again, setup is HP53132A in frequency mode, both external reference port and port A is being fed by a stand-alone PRS-10 10MHz output. Method of dividing signal is just a T connector. Right at the output port of PRS10, there is a T connector, and identical 1m length of coax runs to the counter. Both Ext Ref and Port A gets the signal.

author: tkamiya
author_rank: Super Contributor
timestamp: January 20, 2020, 02:52:33 am
content: With this done, I resumed measuring of my project.I saw odd things. I changed the counter input and started a new measurement. I didn't change a thing on measurement setup screen. Multiplication factor is 10e6. Now, frequency difference screen tells me I'm measuring GHz! Stop and view the data. Sure enough, decimal place is in the wrong place. Remove 10e6 and put 1. It's correct on TimeLab.I guess HP53132A behaves in odd ways.