Re: [time-nuts] Another atomic clock question
Some clarifications on the ADC in the ATmega328 and how it is used in the Arduino GPSDO. The resolution is 10 bits but you can select Vref. In my Arduino GPSDO it is set to the internal Vref = 1.1V so 1LSB is 1.1mV. From the beginning I used 5V as Vref but if you plot the response from the RC-net you find that the useful ADC range is only a fraction if you want to have a reasonable linearity. In the beginning I used only 600 out of the 1024 but still the time per bit was more than a factor two different. If somebody want to experiment with other processors for theTIC, a Teensy with 16bit ADC´s is probably a good idea because you can use only part of the range but still have good resolution (noise is another thing that may be both good and bad in a GPSDO). According to the datasheet the minimum conversion time is 65uSec for the ATmega328 (ADC clock max 200 kHz and 13 clock cycles). The discharge of the 1nF is not 1sec but 1mSec. If it was 1sec, 63% of the previous charge should be left and giving errors up to 63%. My assumption when designing the network was to have at least ten time constants of discharge before the next PPS. So a 100mSec time constant would be fine for that. The problem is that with a 1nF capacitor I would need 100Mohm as discharge resistor. To get 1.1mV (1nS) over 100Mohm you only need 11pA for example from the ADC input leakage current. I decided for 1Mohm that gives 1mv for 1nA. This gives the TIC a drift of about 1ns per nA change. Remember I wished to keep the drift to maybe 1nSs for a couple of degrees room temp change so the drift of the leakage current needs to be below say 0.5nA per degree. My practical testing has showed that I have about 1.2ns drift for 5°C change and it seems consistent between different Arduinos I have. The 1mSec time constant gives a discharge that directly after the pulse from the HC4046 ends is about 0.1% per uSec. So for a 65uSec delay the drop is about 65nS for a 1000nS reading and 32uS for a 500ns reading. If the delay is exactly the same every time it should be possible to compensate for. I have got indication that crosstalk between ADC channels may be a problem in the ATmega328 but with the single TIC and very slowly changing values on the other ADC channels I can´t say it is a problem for me. I also would encourage you to test both the Arduino dual TIC and using both halves of the HC390 whatever I have said about risks. The HC390 is probably not a problem at all for the nS readings as you and Magnus says. Lars Chris wrote: Let's see what is needed. The ADC is 10-bits so it can read to one part in 1024. It's a 5 volt full scale so we are only able to measure 5 millivolt increments The uP runs about 16 million instructions per second. What if we wait 1000 instructions to read the ADC what will the error be? The 1000 number is conservative by at least a factor of 10. The discharge resister has (assume) a one second time constant. The read delay would be 1000/16,000,000 or 63 uSec. in that time the voltage would have changed about 300 microvolts. The change is about 15 times less then the DAC is able to measure.But because of the conservative estimate it might 150 times to small to measure. So randomly delayed reads of the ADC will not matter. That said I'm sure we can do 100X better then the 63 uS estimate. On the other side, charging the cap. Let's say I mis-measured a wire and it is 1cm longer then I though. The added delay adds a tiny delay but this is not going to show up in a 10-bit ADC. Same if the propagation delay changes through the 74HC390 based variable loading of other output pins or noise from the 78ls05 voltage regulator. The DAC is set up for 5 mV steps. I just don't need to worry about errors that are well under 0.5 mV. ___ 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] Finding a spare part for HP5370B
Yes indeed those plastic display covers do seem to fall out and get lost. I have a 5730 with the same issue. Digikey sold (or used to) the red filtered plastic and I have used that to fix an hp8505 that lost a window. Regards Paul WB8TSL On Sat, Mar 8, 2014 at 2:21 AM, Pascual Arbona Lopez p.arb...@securimar.com wrote: Hello! I have been given an HP5370B; I have checked it and it seems to work fine, but unfortunately its missing the red plastic in the display window. If anyone has one of these equipments for spare parts, I would be very grateful if I can buy this part. Please contact me off list if you can help at p.arb...@securimar.com Many thanks P. Arbona ___ 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] SR620 binary dump
Tom, On 04/03/14 01:40, Tom Van Baak wrote: Has anyone used the binary dump feature of the SR620 (command BDMP) or the x1000 feature (command EXPD)? If you have, please send me email off-list. If you haven't, I will post a report to time-nuts later this week. You make me curious. Any specific issue you're having? I haven't tried doing any programming to the SR620 yet, but I have some plans to do 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] Finding a spare part for HP5370B
Yes indeed those plastic display covers do seem to fall out and get lost. I have a 5730 with the same issue. Digikey sold (or used to) the red filtered plastic and I have used that to fix an hp8505 that lost a window. If you live in an area with lots of high-tech, there is probably a local shop that specializes in plastic. In my area, it's TAP Plastics. http://www.tapplastics.com/ http://www.tapplastics.com/about/locations I've only used them once, but they were great. The plastic for a 5370 has a mask on the back side. On the right, it's a stencil to turn diffuse LEDs to text. You could probably make the equivalent by printing on the plastic sheets used with old overhead slide projectors. There is a diagram on page 3-10 of the operating/programming manual. I'll take a picture if that will help. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] New TIC test run
I put my TIC to hardware, and have started testing it. Here is a sample run comparing it against the 5334B with an off frequency OCXO. I've scaled and rotated to tried to cancel out the length of the cables to the 5334B. Still early days with it, yet. http://www.evoria.net/AE6RV/TIC/TICvs5334B.png Bob - AE6RV ___ 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] Another atomic clock question
Hi Hal Not arguing for or against sawtooth or hanging bridges, etc. My needs for GPSDO performance are unquantified but likely quite modest. I just want to get something working that's a bit better than my OCXO. I don't think I need the sawtooth stuff to get started. Thanks jim ab3cv Date: Fri, 07 Mar 2014 21:28:31 -0800 From: Hal Murray hmur...@megapathdsl.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Cc: hmur...@megapathdsl.net Subject: Re: [time-nuts] Another atomic clock question Message-ID: 20140308052831.40d3e406...@ip-64-139-1-69.sjc.megapath.net Content-Type: text/plain; charset=us-ascii j...@jtmiller.com said: I may switch the GPS module at a later date to one which provides sawtooth info if I really feel the need and add a delay line. Frankly I think I'll never get around to it. One nasty problem with hanging bridges is that if you don't believe in them, then you won't setup your monitoring system to notice them. ___ 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] SR620 binary dump
You make me curious. Any specific issue you're having? I haven't tried doing any programming to the SR620 yet, but I have some plans to do it. Cheers, Magnus Hi Magnus, Thanks for asking. Here's an update. I was curious why time interval or period measurements give slightly different results than frequency measurements on a SR620. Maybe the 5370 too. We often advise people to use time interval mode and not frequency mode. Volker's posting got me to dig further. His frequency-data ADEV plots looked too different from his phase-data ADEV plots. It's not just that frequency introduces dead time, but frequency also gives less precise results. But why is this. Ignoring other sources of noise, the 620 interpolator has 2.7 ps numerical granularity (1 / 90 MHz / 4096). It seemed to me that regardless of time interval, period, or frequency mode selection, the identical quantization and noise levels should be evident regardless how one measures an external source(s). So there are two tempting commands to explore. One is BDMP (binary dump) which avoids ascii conversion and gives raw 64-bit binary values. Some people use it to dramatically increase measurement speed over GPIB. The other is EXPD (x1000 expanded resolution). My plan was to use two different exceptionally pure but drifting 10 MHz sources and see to what extent the 620 could measure/compare them. The bad news is that EXPD is not allowed with frequencies above 5 digits (= 1 MHz) so it doesn't apply to 10 MHz inputs. That experiment waits while I make a clean 1 MHz source (e.g., 10 MHz/12 = 833. kHz). In a true time-stamping counter one continuously counts events and continuously counts time. The 620 isn't continuous but it does have two registers, which the manual refers to as the event or cycle counter and the time interval counter. Better yet, page 97 also refers to them as the top and bottom counter. Hint, hint. The binary dump data matches my expectations for period and interval. But for frequency, the 620 does not return the binary values of either the top or bottom counters. Instead it does a fixed point division and returns a scaled top/bottom binary quotient. The net effect is that the ideal BDMP value for a 1 second 10 MHz measurements would be 0x001C71C71C71C71C. (note 0x1C7 / 4095 = 455 / 4095 = 10 / 90, as in 90 MHz). But you never actually get this hex value with a 10 MHz input. With a couple hundred 1-second measurements I saw only one of three values each time: 0x1c71c71c721bf3 = 8006399337569267 = 1000.27126 Hz 0x1c71c71c7270c9 = 8006399337590985 = 1000.54251 Hz 0x1c71c71c72c5a0 = 8006399337612704 = 1000.81379 Hz The delta among these values is 21718 or 21719 counts. So the lower ~16-bits isn't really noise, it's just deterministic quantized residuals from the long-division. And that explains why when the scaled binary values are converted to decimal Hz you get the odd-looking values above. The granularity, or resolution is 27 uHz / 10 MHz = 2.7e-12 = 2.7 ps. Nice, yes? Of hundreds of samples, they were all +1 +2 and +3 times 2.7 ps above nominal. A +0 would give 1000.0 Hz. These BDMP readings have (much) greater resolution that what you get with plain strt;*wai;xall? values. What one normally sees over RS232 or GPIB are ascii readings like: 1.000E7 1.002E7 1.001E7 1.001E7 1.000E7 Note these readings are 0, 100, or 200 uHz from nominal; that is, the granularity is 100 uHz / 10 MHz = 1e-11. Using XREL exposes an additional digit of resolution. Set XREL to 1E7 and then you get ascii readings like: 1.E-4 -6.E-5 2.E-4 -1.4E-4 .0E-6 -1.9E-4 So not only does XREL give you an extra digit of precision but it also transmits fewer bytes. The granularity in this case is 10 uHz / 10 MHz = 1e-12. The hope is that XALL, XREL/XALL, and BDMP agree. But each has different truncation, rounding, and granularity rules. My recommendation is that when making high-precision SR620 10 MHz frequency measurements to use XREL to gain back that least dignificant digit otherwise lost to truncation. Over RS2332/GPIB that's xrel1e7 but you can also do it from the front panel. I'll try this again with EXPD turned on to see what effect that has. I'll also adjust the interpolator calibration tables. The code I used to grab and decode the SR620 binary data is at http://leapsecond.com/tools/620bdmp.c Let me know if you want to jump into this too, or have any corrections/comments. Thanks, /tvb ___ 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] SR620 binary dump
Using XREL exposes an additional digit of resolution. Set XREL to 1E7 and then you get ascii readings like: 1.E-4 -6.E-5 2.E-4 -1.4E-4 .0E-6 -1.9E-4 I should clarify. Yes, it appears that when using XREL, one can get ~2.7 ps timing resolution/granularity for frequency readings 10 MHz. But when the frequency reading is 10 MHz the timing resolution/granularity is 10 ps. For example, here are 1000 measurements using XREL 1E7 (columns are occurrence, value): 1 999.999480 1 999.999510 1 999.999560 1 999.999590 4 999.999620 3 999.999640 9 999.999670 6 999.999700 8 999.999720 22 999.999750 24 999.999780 28 999.999810 50 999.999830 71 999.999860 45 999.999890 73 999.10 122 999.40 54 999.70 294 1000.00 152 1000.000100 28 1000.000200 2 1000.000300 1 1000.000500 Notice how all the readings less than 10 MHz differ by 20 or 30 uHz (mean 27), but all the readings greater than 10 MHz differ by 100 MHz. I will continue to look into this, but my hunch is that this is a bug in the SR620 firmware; the only solution is using binary mode. /tvb ___ 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] SR620 binary dump
...I'll try that, too. Tomorrow. Volker Am 09.03.2014 00:29, schrieb Tom Van Baak: Using XREL exposes an additional digit of resolution. Set XREL to 1E7 and then you get ascii readings like: 1.E-4 -6.E-5 2.E-4 -1.4E-4 .0E-6 -1.9E-4 I should clarify. Yes, it appears that when using XREL, one can get ~2.7 ps timing resolution/granularity for frequency readings 10 MHz. But when the frequency reading is 10 MHz the timing resolution/granularity is 10 ps. For example, here are 1000 measurements using XREL 1E7 (columns are occurrence, value): 1 999.999480 1 999.999510 1 999.999560 1 999.999590 4 999.999620 3 999.999640 9 999.999670 6 999.999700 8 999.999720 22 999.999750 24 999.999780 28 999.999810 50 999.999830 71 999.999860 45 999.999890 73 999.10 122 999.40 54 999.70 294 1000.00 152 1000.000100 28 1000.000200 2 1000.000300 1 1000.000500 Notice how all the readings less than 10 MHz differ by 20 or 30 uHz (mean 27), but all the readings greater than 10 MHz differ by 100 MHz. I will continue to look into this, but my hunch is that this is a bug in the SR620 firmware; the only solution is using binary mode. /tvb ___ 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.
