Re: [time-nuts] Datachron 3070
Hi 10 MHz at roughly 10 dbm is a pretty good bet. That’s *if* it uses an external reference and not just something like IRIG. It’s not really clear that they all do have external reference capability (despite the jack). Bob On Sep 5, 2014, at 1:00 AM, Bob Bownes bow...@gmail.com wrote: Has anyone got a manual for one of these by chance? I'd like to feed in an external oscillator but I'd like to know the frequency and amplitude before I go plugging it in at random. Thanks! Bob ___ 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] OCXO Voltage Input? (Bob Camp)
Hi Bob, Being relatively new to this 'high end' time stuff, there's lots to learn... So, how much bandwidth might a typical OCXO have on the EFC pin? My assumption is that it is very low, but I have nothing to back that up. If I had 10Mhz or some other high frequency on the EFC line, would a typical OCXO respond to that? The concern is that any HF noise on the power pins of the driving op-amp might make it onto the EFC line. Of course most amps have good PSRR at low frequencies. If the EFC pin only has low frequency response, there shouldn't be an issue. Are there any OCXO schematics out on the web, that one could study? Dan On 9/5/2014 7:02 AM, time-nuts-requ...@febo.com wrote: Hi The EFC pin *might* have a bypass cap on it. If you drive it with an op-amp an isolating resistor might be needed. If so, a couple hundred ohms is likely enough to stabilize the op-amp. In a closed loop / control loop setting, the noise on the EFC will be whatever the loop generates. As long as you stay with good quality op-amps and low impedances in your filters, things should be plenty quiet. Things like EFC range, output frequency, phase noise, and intended use / circuit would be needed to come up with more specific information. Bob ___ 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] OCXO Voltage Input? (Bob Camp)
Some OCXO schematics: http://leapsecond.com/museum/10544/ http://leapsecond.com/museum/10811a/ /tvb (i5s) On Sep 5, 2014, at 5:50 AM, Dan Kemppainen d...@irtelemetrics.com wrote: Hi Bob, Being relatively new to this 'high end' time stuff, there's lots to learn... So, how much bandwidth might a typical OCXO have on the EFC pin? My assumption is that it is very low, but I have nothing to back that up. If I had 10Mhz or some other high frequency on the EFC line, would a typical OCXO respond to that? The concern is that any HF noise on the power pins of the driving op-amp might make it onto the EFC line. Of course most amps have good PSRR at low frequencies. If the EFC pin only has low frequency response, there shouldn't be an issue. Are there any OCXO schematics out on the web, that one could study? Dan On 9/5/2014 7:02 AM, time-nuts-requ...@febo.com wrote: Hi The EFC pin *might* have a bypass cap on it. If you drive it with an op-amp an isolating resistor might be needed. If so, a couple hundred ohms is likely enough to stabilize the op-amp. In a closed loop / control loop setting, the noise on the EFC will be whatever the loop generates. As long as you stay with good quality op-amps and low impedances in your filters, things should be plenty quiet. Things like EFC range, output frequency, phase noise, and intended use / circuit would be needed to come up with more specific information. Bob ___ 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] OCXO Voltage Input? (Bob Camp)
Oh, while we are at it, how about the 10543? Cheers, Magnus On 09/05/2014 03:49 PM, Tom Van Baak (lab) wrote: Some OCXO schematics: http://leapsecond.com/museum/10544/ http://leapsecond.com/museum/10811a/ /tvb (i5s) On Sep 5, 2014, at 5:50 AM, Dan Kemppainen d...@irtelemetrics.com wrote: Hi Bob, Being relatively new to this 'high end' time stuff, there's lots to learn... So, how much bandwidth might a typical OCXO have on the EFC pin? My assumption is that it is very low, but I have nothing to back that up. If I had 10Mhz or some other high frequency on the EFC line, would a typical OCXO respond to that? The concern is that any HF noise on the power pins of the driving op-amp might make it onto the EFC line. Of course most amps have good PSRR at low frequencies. If the EFC pin only has low frequency response, there shouldn't be an issue. Are there any OCXO schematics out on the web, that one could study? Dan On 9/5/2014 7:02 AM, time-nuts-requ...@febo.com wrote: Hi The EFC pin *might* have a bypass cap on it. If you drive it with an op-amp an isolating resistor might be needed. If so, a couple hundred ohms is likely enough to stabilize the op-amp. In a closed loop / control loop setting, the noise on the EFC will be whatever the loop generates. As long as you stay with good quality op-amps and low impedances in your filters, things should be plenty quiet. Things like EFC range, output frequency, phase noise, and intended use / circuit would be needed to come up with more specific information. Bob ___ 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.
[time-nuts] Oscilloquartz 3210 Cesium Standard
Hi Tom, Just catching up and time for an update on progress. Had had to put the faulty 3210 to one side this week to get some work done, but a couple of developments meantime: First: Put an enquiry on the Oscilloquartz web enquiry form a week or so ago and they sent me the full 3210 pdf manual. Theory, adjustments and full schematics. Needless to say very grateful and sent back an email thanking them. Although there were no conditions attached, I have to assume it was sent in confidence, so can't upload to a file share site, but if anyone needs a copy, please contact me off list. Thanks to Tom for scanning his manual as well. It looks like an earlier version than I have and there seem to be minor differences, so a scan of the whole thing would be good, if possible. I have a Panasonic doc scanner, A4 A3, long and user defined pages, colour etc (Ebay, 20 ukp :-) and could scan the whole volume if you are in the UK. Second: I had a possible line on two more of these 3210's and offer accepted, collected them yesterday. One blows the line fuse, which should be simple fix, but the other one actually works. Ion current way off scale to start, with one psu rail cycling on and off, but after an hour or two, lock light on and integrator starting to fall back as the OCXO warmed up. The 2nd harmonic, which was zero on the original unit, started creeping up from just visible indication, to 4 of 10 after ~5 hours, then after running all night, shows full scale at 10, Utopia :-). Valid range from the manual is 2-10, so this looks like a very good tube. Am going to leave it running for a month, then go right through the setup procedure. Both units collected yesterday were each in a small subrack, with Racal badged standbye psu + batteries and the whole rack marked as Portable Frequency Standard. That is, take to a site, power up, calibrate whatever, then power down and put back in store. They may have done very few hours, but that may be wishful thinking. Two still to fix then, but now have a working unit for comparison and at last, a properly working cesium standard for the lab. Thanks to everyone who replied here along the way, the response and encouragement have been amazing... Regards, Chris cc this to tvb, in case this doesn't reach the list... ___ 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] OCXO Voltage Input? (Bob Camp)
Tom, Awesome! Thanks! Section 2-14. Since noise on the EFC line affects the oscillator's stability (noise appears as FM on the output) care must be taken to ensure that a relatively noise free EFC... I was thinking the Varactor had be tied to the crystal, which only makes sense. So, the bottom line is the EFC inputs are probably susceptible to HF noise... The bottom line is, it's worth while ensuring the EFC amp and EFC signal are as clean as possible. Good stuff to know! Thanks! Dan On 9/5/2014 12:00 PM, time-nuts-requ...@febo.com wrote: Some OCXO schematics: http://leapsecond.com/museum/10544/ http://leapsecond.com/museum/10811a/ /tvb (i5s) ___ 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] Poor Mans TIC (Using Beaglebone onboard PRU)
Ian Have not downloaded the info yet. But I was surprised by the fact you were using LORAN sooo you must be in Europe. Lucky you to have such a fine signal. Great job on the tic. Now to go download the bits. Thanks again. Regards Paul. On Sun, Aug 31, 2014 at 10:26 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Iain, Thanks very much for posting, and for sharing the code. I know many of us are interested in how well modern CPU's or SBC's can be used as time interval, time stamping, and frequency counting instruments. I know the BB PRU's have been mentioned before on the list but it's really nice to see actual code and test results. About the hp 5370 -- realize that these are still 1000x more precise (on the order of tens of ps) than what a BB/PRU is capable of (on the order of tens of ns). But as you observe, they key point is -- for mid- to long-term measurement of free-running time/frequency standards you do not necessarily need ps-level measurement capability. Nanosecond, or even microsecond time resolution is more than enough to create comprehensive plots of time and frequency drift over the long-term. Again, thanks. /tvb - Original Message - From: Iain Young i...@g7iii.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, August 31, 2014 1:24 PM Subject: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU) Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised. In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the A clock to go high, and then counts until B goes high, resets it's counters, and waits for A to go high again. It also keeps track of a sequence number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue. I'll have to look if there's a better way to do the shared memory stuff (interrupts, signaling etc), or store multiple intervals and send them all at once, although the current code seems pretty tight. I'd like to have tried it with 1MHz, 5MHz, and even 10 MHz clocks, as 20nS resolution will handle that, but I think I need to fix the 11uS separation issue first. Then again, it was written to compare PPS's from different Austron 2100's and GPS. It also took less than 24 hours from concept to running :) If anyone wants it, the code is here here: http://hal.g7iii.net/bb_tic/ You will need the pasm compiler, and probably the am335x PRU package, although there are (tiny) binaries there as well Setup, Compile, and Running instructions are included in README.txt Oh, Sample output: PRU0: Seq No:848 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.11700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.11660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.11660 seconds You can plainly see the Austron has a jitter of around +/-20 ns from the GPS PPS (figures confirmed with the 5370). Slew was around 11.5us. I must wire up the other two Austron's but will need to
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
Ian what files are needed? Forgive me if its in the read me. Thanks On Fri, Sep 5, 2014 at 2:56 PM, paul swed paulsw...@gmail.com wrote: Ian Have not downloaded the info yet. But I was surprised by the fact you were using LORAN sooo you must be in Europe. Lucky you to have such a fine signal. Great job on the tic. Now to go download the bits. Thanks again. Regards Paul. On Sun, Aug 31, 2014 at 10:26 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Iain, Thanks very much for posting, and for sharing the code. I know many of us are interested in how well modern CPU's or SBC's can be used as time interval, time stamping, and frequency counting instruments. I know the BB PRU's have been mentioned before on the list but it's really nice to see actual code and test results. About the hp 5370 -- realize that these are still 1000x more precise (on the order of tens of ps) than what a BB/PRU is capable of (on the order of tens of ns). But as you observe, they key point is -- for mid- to long-term measurement of free-running time/frequency standards you do not necessarily need ps-level measurement capability. Nanosecond, or even microsecond time resolution is more than enough to create comprehensive plots of time and frequency drift over the long-term. Again, thanks. /tvb - Original Message - From: Iain Young i...@g7iii.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, August 31, 2014 1:24 PM Subject: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU) Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised. In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the A clock to go high, and then counts until B goes high, resets it's counters, and waits for A to go high again. It also keeps track of a sequence number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue. I'll have to look if there's a better way to do the shared memory stuff (interrupts, signaling etc), or store multiple intervals and send them all at once, although the current code seems pretty tight. I'd like to have tried it with 1MHz, 5MHz, and even 10 MHz clocks, as 20nS resolution will handle that, but I think I need to fix the 11uS separation issue first. Then again, it was written to compare PPS's from different Austron 2100's and GPS. It also took less than 24 hours from concept to running :) If anyone wants it, the code is here here: http://hal.g7iii.net/bb_tic/ You will need the pasm compiler, and probably the am335x PRU package, although there are (tiny) binaries there as well Setup, Compile, and Running instructions are included in README.txt Oh, Sample output: PRU0: Seq No:848 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.11700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.11660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.11660 seconds You can plainly see the Austron has a jitter of around
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
Hey Paul, Grab the tarball, it contains each of the other files in that directory. And yes, the README tells you what you need to do. Note you will need the PRUSS compiler end probably the AM335x PRU Package to compile. Google for it, or grab this one via git: https://github.com/rjw245/am335x_pru_package/ [Not mine, but used the inputtest example as a base]. Dump the files in the inputtest directory (or create a new one at the same level), then do the pasm and make stuff. To get started quickly, tic_ab_dualpru, tic_ab_pru0.bin, and tic_ab_pru1.bin, and just run tic_ab_dualpru. This will work on a BBW. I am currently playing with it on the BBB, and have discovered I can go to 10ns resolution, but the code needs adjusting (seems the PRUs might be running at a different speed to the BBW, I need to investigate!) I also still have the 10-11uS issue mentioned below, but I am unconvinced I have the pin-mux settings quite right yet (I think they are being passed back through the SOC-fabric, thus slowing things down!) I'll probably post an update over the weekend (not had chance to play all week due to work commitments) Iain On 05/09/14 20:09, paul swed wrote: Ian what files are needed? Forgive me if its in the read me. Thanks On Fri, Sep 5, 2014 at 2:56 PM, paul swed paulsw...@gmail.com wrote: Ian Have not downloaded the info yet. But I was surprised by the fact you were using LORAN sooo you must be in Europe. Lucky you to have such a fine signal. Great job on the tic. Now to go download the bits. Thanks again. Regards Paul. On Sun, Aug 31, 2014 at 10:26 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Iain, Thanks very much for posting, and for sharing the code. I know many of us are interested in how well modern CPU's or SBC's can be used as time interval, time stamping, and frequency counting instruments. I know the BB PRU's have been mentioned before on the list but it's really nice to see actual code and test results. About the hp 5370 -- realize that these are still 1000x more precise (on the order of tens of ps) than what a BB/PRU is capable of (on the order of tens of ns). But as you observe, they key point is -- for mid- to long-term measurement of free-running time/frequency standards you do not necessarily need ps-level measurement capability. Nanosecond, or even microsecond time resolution is more than enough to create comprehensive plots of time and frequency drift over the long-term. Again, thanks. /tvb - Original Message - From: Iain Young i...@g7iii.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, August 31, 2014 1:24 PM Subject: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU) Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised. In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the A clock to go high, and then counts until B goes high, resets it's counters, and waits for A to go high again. It also keeps track of a sequence number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue. I'll have to look if there's a better way to do the shared memory stuff (interrupts, signaling etc), or store multiple intervals and send them all at once, although the current code seems pretty tight. I'd like to have tried it with 1MHz, 5MHz, and even 10 MHz clocks, as 20nS resolution will handle that, but I think I need to fix the 11uS separation issue first. Then again, it was written to compare PPS's from different Austron 2100's and GPS. It also took less than 24 hours from concept to running :) If anyone wants it, the code is here here: http://hal.g7iii.net/bb_tic/ You will need the pasm compiler, and probably the
Re: [time-nuts] OCXO Voltage Input? (Bob Camp)
no that is not so bad, there --inside of the box is always a small RC which takes care the RF can't get into the oscillator, just look the oscillator circuirs 73 Alex On 9/5/2014 10:18 AM, Dan Kemppainen wrote: Tom, Awesome! Thanks! Section 2-14. Since noise on the EFC line affects the oscillator's stability (noise appears as FM on the output) care must be taken to ensure that a relatively noise free EFC... I was thinking the Varactor had be tied to the crystal, which only makes sense. So, the bottom line is the EFC inputs are probably susceptible to HF noise... The bottom line is, it's worth while ensuring the EFC amp and EFC signal are as clean as possible. Good stuff to know! Thanks! Dan On 9/5/2014 12:00 PM, time-nuts-requ...@febo.com wrote: Some OCXO schematics: http://leapsecond.com/museum/10544/ http://leapsecond.com/museum/10811a/ /tvb (i5s) ___ 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] Update on my Arduino GPSDO / NTP server - going atomic
After some productive work, and some frustrating weeks spent fighting weird flakiness and needlessly replacing components, only to find that the problems went away after I reseated my main power connector, IT WORKS! Here's where I am now: * Main board: Arduino Due (ATSAM3X ARM Cortex-M3 CPU @ 84MHz) * Oscillator: Symmetricom X72. * GPS: Trimble Resolution T with a cheap Gilsson puck antenna. * Ethernet: Wiznet W5100. The X72 is used to externally clock one of the ARM's hardware timer/counters at 10MHz (I'm not multiplying it up and using it to clock the CPU). The same timer timestamps the rising edge of the PPS using capture mode, jitter free @ 100ns resolution. All the PLL is done digitally using these values and the adjustment is sent to the X72 over serial (DDS, 2 ppt resolution). After about a day's solid running, the PPS phase stays within +/- 100ns as measured on the board itself, even out to a PLL tau of 1 hour, and the frequency adjust stays within 1 ppt when 5-minute averaged. I'm collecting data against an outside reference now (PPS generated by the board against the PPS of a Spectracom NetClock with OCXO option). Too early for graphs, but it looks good. On the Ethernet end, things are less good, but still respectable -- about 10us RMS added jitter. I think a lot of this is introduced by the W5100, and I'm working on getting my hands on a board that uses the same chip but actually makes use of the onchip Ethernet MAC that the Arduino doesn't bother to route, which should help substantially. Already it's better than conventional wisdom says NTP gets :) Questions I still have: 1. Should I try using the analog EFC to zero out the amount of correction I ask the X72's DDS for? Could reduce jitter in the timebase, could just add noise. I suppose I can test this one easily enough. 2. Is there any point in decoding the sawtooth correction from the GPS, or in wiring up the PICTIC and using it to measure the GPS offset more accurately, when my clock granularity is 100ns anyway? I suppose at best I'd be improving my accuracy from +/- 1.5 ticks to +/- 0.5 ticks. 3. Anything else I should consider? If anyone is curious, code is at https://github.com/arodland/Due-GPS-NTP-Server . Thanks for following, Andrew On Tue, Jul 29, 2014 at 12:42 AM, Andrew Rodland and...@cleverdomain.org wrote: Hi all, After a couple years not doing anything except letting it sit in my den and provide time for my home network, I've decided to start hacking on my hobby project again. For reference, what I've got right now is a Freetronics EtherMega (ATMega2560-based Arduino clone with integrated W5100 ethernet), wired up to a USGlobalSat ET-318-02 (a pretty cheap consumer SiRF-III module). It runs totally custom timekeeping, PLL, and NTP protocol code. The timebase is the onboard crystal, which I have no way of influencing directly, so it basically does DDS, adding or duplicating the occasional tick to keep lock. For such a ramshackle collection of equipment it does a pretty good job, tracking within around 10us of a Spectracom NetClock (and showing less Ethernet-induced jitter than the NetClock itself) I've been thinking for years about building a next-gen version, and sketched a few designs, but I could never quite find a board that I wanted to use as the core of it. Well, Freetronics sent me a product announcement for their EtherDue board (built around the ATSAM3X, which is an ARM Cortex-M3 chip from AVR), I read some specs, and decided to dive in. I've got a working, tuned-up LPRO-101, and I always figured that my next build would desolder the clock crystal and use the Rb as the CPU timebase, like most builds I've seen do. But I realized that the ATSAM3X is happy to run its timer/counters off of an external clock as long as it's less than 1:2.5 the CPU clock. 10MHz fits that bill. I lose a little bit on granularity by not letting the CPU multiply that up 8x for me, but probably no real change in accuracy. Just feed the Rb to a pair of pins and get a register that counts up every 100ns, seems simple! For locking to the PPS I could do the usual thing and use input capture on the timer clocked by the Rb, which would handily timestamp the rising edge of the PPS. But I have a couple of PICTIC IIs laying around, and I'm a bit tempted to instead use the timer to generate a PPS from my board and let the PICTICs compare. Since START has to come before STOP I figure I need two of them in parallel, only listen to the one that gives a report 0.5 seconds, and which one gives me the sign. Does that make sense? Or should I just use one and lock to a nonzero offset? I've found surprisingly little material on the tricks of using a TIC in a digital GPSDO. Finally there's adjusting the Rb. It would be nice to be able to slew nice and gently by actually nudging the clock instead of adding/dropping them, especially if I have the PICTIC to give me precision offsets. I'm not sure whether
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
Ian Thank you On Fri, Sep 5, 2014 at 3:54 PM, Iain Young i...@g7iii.net wrote: Hey Paul, Grab the tarball, it contains each of the other files in that directory. And yes, the README tells you what you need to do. Note you will need the PRUSS compiler end probably the AM335x PRU Package to compile. Google for it, or grab this one via git: https://github.com/rjw245/am335x_pru_package/ [Not mine, but used the inputtest example as a base]. Dump the files in the inputtest directory (or create a new one at the same level), then do the pasm and make stuff. To get started quickly, tic_ab_dualpru, tic_ab_pru0.bin, and tic_ab_pru1.bin, and just run tic_ab_dualpru. This will work on a BBW. I am currently playing with it on the BBB, and have discovered I can go to 10ns resolution, but the code needs adjusting (seems the PRUs might be running at a different speed to the BBW, I need to investigate!) I also still have the 10-11uS issue mentioned below, but I am unconvinced I have the pin-mux settings quite right yet (I think they are being passed back through the SOC-fabric, thus slowing things down!) I'll probably post an update over the weekend (not had chance to play all week due to work commitments) Iain On 05/09/14 20:09, paul swed wrote: Ian what files are needed? Forgive me if its in the read me. Thanks On Fri, Sep 5, 2014 at 2:56 PM, paul swed paulsw...@gmail.com wrote: Ian Have not downloaded the info yet. But I was surprised by the fact you were using LORAN sooo you must be in Europe. Lucky you to have such a fine signal. Great job on the tic. Now to go download the bits. Thanks again. Regards Paul. On Sun, Aug 31, 2014 at 10:26 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Iain, Thanks very much for posting, and for sharing the code. I know many of us are interested in how well modern CPU's or SBC's can be used as time interval, time stamping, and frequency counting instruments. I know the BB PRU's have been mentioned before on the list but it's really nice to see actual code and test results. About the hp 5370 -- realize that these are still 1000x more precise (on the order of tens of ps) than what a BB/PRU is capable of (on the order of tens of ns). But as you observe, they key point is -- for mid- to long-term measurement of free-running time/frequency standards you do not necessarily need ps-level measurement capability. Nanosecond, or even microsecond time resolution is more than enough to create comprehensive plots of time and frequency drift over the long-term. Again, thanks. /tvb - Original Message - From: Iain Young i...@g7iii.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, August 31, 2014 1:24 PM Subject: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU) Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised. In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the A clock to go high, and then counts until B goes high, resets it's counters, and waits for A to go high again. It also keeps track of a sequence number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue. I'll have to look if there's a better way to do the shared memory stuff (interrupts, signaling etc), or store multiple intervals and send them all at once, although the current code seems pretty tight. I'd like to have tried it with 1MHz, 5MHz, and even 10 MHz clocks, as 20nS resolution will handle that, but I think I need to fix the 11uS separation issue first. Then again, it was written to compare PPS's from different Austron 2100's and GPS. It
Re: [time-nuts] OCXO Voltage Input? (Bob Camp)
d...@irtelemetrics.com said: If I had 10Mhz or some other high frequency on the EFC line, would a typical OCXO respond to that? Some VCXOs actually specify their bandwidth. High audio is sometimes useful. I haven't seen anything beyond that, but I'm just listening to discussions like this one. There could well be applications that use a higher frequency. One application is correcting for mechanical vibrations. This is interesting in radar used on helicopters. (They do Doppler filtering to remove clutter. The lower speed of objects that can get through the filter depends on the clock stability.) PCs often FM modulate their clocks. It's a hack to get past the FCC EMI requirements. It spreads a spike in the frequency domain into a blob with a lower peak. I think 30 KHz is typical. The PCI specs were tweaked to allow this so they probably say something about the legal frequency limit. PCs probably don't use expensive OCXOs, but that technology might get used in other applications. How do FM modulators work? -- 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.
Re: [time-nuts] Update on my Arduino GPSDO / NTP server - going atomic
Andrew, My only comment, since I’m working on something very similar myself (just a GPS frequency standard that will be able to have the OCXO shut off, and just output 1PPS for an NTP system), would be to not output any signal/pps/ntp timing unless you have a solid GPS lock, since before that, I would assume your PLL loop is sweeping. But I’m sure that’s already in your code… just didn’t look through it all. =) Cool idea though. I’ve found very few (none) instances of people actually running NTP servers from arduino hardware… most use Raspi or the like. Thanks! -Ryan Stasel On Sep 5, 2014, at 12:07 , Andrew Rodland and...@cleverdomain.org wrote: After some productive work, and some frustrating weeks spent fighting weird flakiness and needlessly replacing components, only to find that the problems went away after I reseated my main power connector, IT WORKS! Here's where I am now: * Main board: Arduino Due (ATSAM3X ARM Cortex-M3 CPU @ 84MHz) * Oscillator: Symmetricom X72. * GPS: Trimble Resolution T with a cheap Gilsson puck antenna. * Ethernet: Wiznet W5100. The X72 is used to externally clock one of the ARM's hardware timer/counters at 10MHz (I'm not multiplying it up and using it to clock the CPU). The same timer timestamps the rising edge of the PPS using capture mode, jitter free @ 100ns resolution. All the PLL is done digitally using these values and the adjustment is sent to the X72 over serial (DDS, 2 ppt resolution). After about a day's solid running, the PPS phase stays within +/- 100ns as measured on the board itself, even out to a PLL tau of 1 hour, and the frequency adjust stays within 1 ppt when 5-minute averaged. I'm collecting data against an outside reference now (PPS generated by the board against the PPS of a Spectracom NetClock with OCXO option). Too early for graphs, but it looks good. On the Ethernet end, things are less good, but still respectable -- about 10us RMS added jitter. I think a lot of this is introduced by the W5100, and I'm working on getting my hands on a board that uses the same chip but actually makes use of the onchip Ethernet MAC that the Arduino doesn't bother to route, which should help substantially. Already it's better than conventional wisdom says NTP gets :) Questions I still have: 1. Should I try using the analog EFC to zero out the amount of correction I ask the X72's DDS for? Could reduce jitter in the timebase, could just add noise. I suppose I can test this one easily enough. 2. Is there any point in decoding the sawtooth correction from the GPS, or in wiring up the PICTIC and using it to measure the GPS offset more accurately, when my clock granularity is 100ns anyway? I suppose at best I'd be improving my accuracy from +/- 1.5 ticks to +/- 0.5 ticks. 3. Anything else I should consider? If anyone is curious, code is at https://github.com/arodland/Due-GPS-NTP-Server . Thanks for following, Andrew On Tue, Jul 29, 2014 at 12:42 AM, Andrew Rodland and...@cleverdomain.org wrote: Hi all, After a couple years not doing anything except letting it sit in my den and provide time for my home network, I've decided to start hacking on my hobby project again. For reference, what I've got right now is a Freetronics EtherMega (ATMega2560-based Arduino clone with integrated W5100 ethernet), wired up to a USGlobalSat ET-318-02 (a pretty cheap consumer SiRF-III module). It runs totally custom timekeeping, PLL, and NTP protocol code. The timebase is the onboard crystal, which I have no way of influencing directly, so it basically does DDS, adding or duplicating the occasional tick to keep lock. For such a ramshackle collection of equipment it does a pretty good job, tracking within around 10us of a Spectracom NetClock (and showing less Ethernet-induced jitter than the NetClock itself) I've been thinking for years about building a next-gen version, and sketched a few designs, but I could never quite find a board that I wanted to use as the core of it. Well, Freetronics sent me a product announcement for their EtherDue board (built around the ATSAM3X, which is an ARM Cortex-M3 chip from AVR), I read some specs, and decided to dive in. I've got a working, tuned-up LPRO-101, and I always figured that my next build would desolder the clock crystal and use the Rb as the CPU timebase, like most builds I've seen do. But I realized that the ATSAM3X is happy to run its timer/counters off of an external clock as long as it's less than 1:2.5 the CPU clock. 10MHz fits that bill. I lose a little bit on granularity by not letting the CPU multiply that up 8x for me, but probably no real change in accuracy. Just feed the Rb to a pair of pins and get a register that counts up every 100ns, seems simple! For locking to the PPS I could do the usual thing and use input capture on the timer clocked by the Rb, which would handily timestamp the rising edge of the PPS. But I
Re: [time-nuts] OCXO Voltage Input?
The schematic provided shows two 20K resistors in series with the varactor. So, yes there is some RC time constant. But is it enough to filter our 100Hz or 1Khz, or 100Khz? I'll have to pull out the calculator. The other issue, is I don't know how my OCXO is built. No schematic. Also, don't forget, this is time nuts. Better is better, is it not? :) Dan no that is not so bad, there --inside of the box is always a small RC which takes care the RF can't get into the oscillator, just look the oscillator circuirs 73 Alex On 9/5/2014 10:18 AM, Dan Kemppainen wrote: Tom, Awesome! Thanks! Section 2-14. Since noise on the EFC line affects the oscillator's stability (noise appears as FM on the output) care must be taken to ensure that a relatively noise free EFC... I was thinking the Varactor had be tied to the crystal, which only makes sense. So, the bottom line is the EFC inputs are probably susceptible to HF noise... The bottom line is, it's worth while ensuring the EFC amp and EFC signal are as clean as possible. Good stuff to know! Thanks! Dan ___ 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] Poor Mans TIC (Using Beaglebone onboard PRU)
This is interesting. Im in the process of building my first GPSDO, it would be interesting to use the PRU to monitor and validate that device, obviously to the limit of the PRU's accuracy. I have several BBB's sitting here waiting for a project. On Sat, Sep 6, 2014 at 7:14 AM, paul swed paulsw...@gmail.com wrote: Ian Thank you On Fri, Sep 5, 2014 at 3:54 PM, Iain Young i...@g7iii.net wrote: Hey Paul, Grab the tarball, it contains each of the other files in that directory. And yes, the README tells you what you need to do. Note you will need the PRUSS compiler end probably the AM335x PRU Package to compile. Google for it, or grab this one via git: https://github.com/rjw245/am335x_pru_package/ [Not mine, but used the inputtest example as a base]. Dump the files in the inputtest directory (or create a new one at the same level), then do the pasm and make stuff. To get started quickly, tic_ab_dualpru, tic_ab_pru0.bin, and tic_ab_pru1.bin, and just run tic_ab_dualpru. This will work on a BBW. I am currently playing with it on the BBB, and have discovered I can go to 10ns resolution, but the code needs adjusting (seems the PRUs might be running at a different speed to the BBW, I need to investigate!) I also still have the 10-11uS issue mentioned below, but I am unconvinced I have the pin-mux settings quite right yet (I think they are being passed back through the SOC-fabric, thus slowing things down!) I'll probably post an update over the weekend (not had chance to play all week due to work commitments) Iain On 05/09/14 20:09, paul swed wrote: Ian what files are needed? Forgive me if its in the read me. Thanks On Fri, Sep 5, 2014 at 2:56 PM, paul swed paulsw...@gmail.com wrote: Ian Have not downloaded the info yet. But I was surprised by the fact you were using LORAN sooo you must be in Europe. Lucky you to have such a fine signal. Great job on the tic. Now to go download the bits. Thanks again. Regards Paul. On Sun, Aug 31, 2014 at 10:26 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Iain, Thanks very much for posting, and for sharing the code. I know many of us are interested in how well modern CPU's or SBC's can be used as time interval, time stamping, and frequency counting instruments. I know the BB PRU's have been mentioned before on the list but it's really nice to see actual code and test results. About the hp 5370 -- realize that these are still 1000x more precise (on the order of tens of ps) than what a BB/PRU is capable of (on the order of tens of ns). But as you observe, they key point is -- for mid- to long-term measurement of free-running time/frequency standards you do not necessarily need ps-level measurement capability. Nanosecond, or even microsecond time resolution is more than enough to create comprehensive plots of time and frequency drift over the long-term. Again, thanks. /tvb - Original Message - From: Iain Young i...@g7iii.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, August 31, 2014 1:24 PM Subject: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU) Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised. In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the A clock to go high, and then counts until B goes high, resets it's counters, and waits for A to go high again. It also keeps track of a sequence number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue.
Re: [time-nuts] OCXO Voltage Input? (Bob Camp)
it is not so easy to FM modulate a crystal oscillator, since the crystal has a high Q therefore the modulation bandwidth of a crystal oscillator is very narrow example: Q = F/dF - df = F/Q if F = 10MHz, Q = 60,000 dF = 166Hz 73 KJ6UHN Alex On 9/5/2014 1:10 PM, Hal Murray wrote: d...@irtelemetrics.com said: If I had 10Mhz or some other high frequency on the EFC line, would a typical OCXO respond to that? Some VCXOs actually specify their bandwidth. High audio is sometimes useful. I haven't seen anything beyond that, but I'm just listening to discussions like this one. There could well be applications that use a higher frequency. One application is correcting for mechanical vibrations. This is interesting in radar used on helicopters. (They do Doppler filtering to remove clutter. The lower speed of objects that can get through the filter depends on the clock stability.) PCs often FM modulate their clocks. It's a hack to get past the FCC EMI requirements. It spreads a spike in the frequency domain into a blob with a lower peak. I think 30 KHz is typical. The PCI specs were tweaked to allow this so they probably say something about the legal frequency limit. PCs probably don't use expensive OCXOs, but that technology might get used in other applications. How do FM modulators work? ___ 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] Measurement of noise voltage density on batteries from 0.1 Hz .. 1MHz
I have made some measurements on the noise voltage density in batteries. The short result is: 1. NiCd rulez. 2. Size DOES matter. A longer result is under http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf You must use the direct link, it is not yet connected to the text of the web site. regards, Gerhard yes, Pb and LithiumIronPhosphate are still missing. ___ 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] Update on my Arduino GPSDO / NTP server - going atomic
On Fri, Sep 5, 2014 at 2:28 PM, Ryan Stasel rsta...@uoregon.edu wrote: Cool idea though. I’ve found very few (none) instances of people actually running NTP servers from arduino hardware… most use Raspi or the like. Note the Arduino Due has an ARM based CPU inside. It's not jet the old AVR chip. It is more than enough for NTP. Arduino is now a WIDE range of products all the way for from this is the tiny $3 Chinese versions. -- Chris Albertson Redondo Beach, California ___ 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] OCXO Voltage Input? (Bob Camp)
Hi Oddly enough (and yes it is odd) you can modulate an oscillator well outside the crystal’s bandwidth. The bigger issue is that the EFC does not pull the crystal very far on a normal OCXO. The FM modulation index drops to very small numbers pretty fast as you go up in modulation frequency. You typically only worry about modulation sidebands that are above the phase noise floor. Since phase modulation sidebands go down as 1/Fmod on an FM modulator (for small modulation index) they get pretty low pretty fast. If your OCXO has an EFC range of 0.1 ppm at 10 MHz, it will swing 1 Hz p-p (+/- 0.5 Hz) for the full EFC voltage. At 5 Hz, you have a modulation index of 0.1. Of course if you are multiplying to 10 GHz, the index could be quite large. This gets back to the “this all depends on what you are doing”. If your EFC is 5V, a reasonably quiet signal would have noise below 0.5 mV. That’s already 80 db down. A very quiet supply should be in the 5 nV / sqrt(Hz) range. That would put the noise down 180 db. It’s unlikely that your OCXO has a phase noise spec of -180 dbc / Hz at 10 Hz. We may already be done … To bring all the numbers together: At 1 Hz the modulation will do a sideband X db down at your desired frequency. You will drop 20 db by the time you get to 10 Hz simply due to the 1/F FM-PM. You are 80 or 180 db down (depending on your EFC) beyond that. So you are at X - 20 - 80 or 100 db below your 1Hz sideband. (noisy EFC) Chances are (unless you are at microwaves), you are well below the phase noise floor already. You are X - 20 - 180 or 200 db below the 1 Hz sideband (quiet EFC). Even at microwaves, you are below the phase noise floor. Most likely you are below it by 80 db. Bottom line - it’s not all that hard to get a quiet enough EFC voltage. Bob On Sep 5, 2014, at 7:32 PM, Alex Pummer a...@pcscons.com wrote: it is not so easy to FM modulate a crystal oscillator, since the crystal has a high Q therefore the modulation bandwidth of a crystal oscillator is very narrow example: Q = F/dF - df = F/Q if F = 10MHz, Q = 60,000 dF = 166Hz 73 KJ6UHN Alex On 9/5/2014 1:10 PM, Hal Murray wrote: d...@irtelemetrics.com said: If I had 10Mhz or some other high frequency on the EFC line, would a typical OCXO respond to that? Some VCXOs actually specify their bandwidth. High audio is sometimes useful. I haven't seen anything beyond that, but I'm just listening to discussions like this one. There could well be applications that use a higher frequency. One application is correcting for mechanical vibrations. This is interesting in radar used on helicopters. (They do Doppler filtering to remove clutter. The lower speed of objects that can get through the filter depends on the clock stability.) PCs often FM modulate their clocks. It's a hack to get past the FCC EMI requirements. It spreads a spike in the frequency domain into a blob with a lower peak. I think 30 KHz is typical. The PCI specs were tweaked to allow this so they probably say something about the legal frequency limit. PCs probably don't use expensive OCXOs, but that technology might get used in other applications. How do FM modulators work? ___ 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] 10811 Thermal fuse?
Panasonic EYP-1BF115 Thermal Cutoff 115C 1A, part number P10912 from Digikey is a perfect fit to replace the original -hp- part. Dan ___ 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] Update on my Arduino GPSDO / NTP server - going atomic
On Sep 5, 2014, at 17:34 , Chris Albertson albertson.ch...@gmail.com wrote: On Fri, Sep 5, 2014 at 2:28 PM, Ryan Stasel rsta...@uoregon.edu wrote: Cool idea though. I’ve found very few (none) instances of people actually running NTP servers from arduino hardware… most use Raspi or the like. Note the Arduino Due has an ARM based CPU inside. It's not jet the old AVR chip. It is more than enough for NTP. Arduino is now a WIDE range of products all the way for from this is the tiny $3 Chinese versions Oh sure, I know. Still hadn’t seen any NTP servers on the Arduino platform in general… clients yes, but no servers. So anyway, very cool. =) Thanks! ___ 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] Measurement of noise voltage density on batteries
Gerhard wrote: I have made some measurements on the noise voltage density in batteries. The short result is: 1. NiCd rulez. 2. Size DOES matter. Nice work! (But not exactly news.) As noted in the NIST paper you quote, the noise of batteries is very closely correlated with their internal resistance, because the primary noise mechanism is Johnson noise and NiCads have the lowest internal resistance of commonly available batteries. As you discovered, the internal resistance of many NiMH batteries rises when current is drawn (one of the great drawbacks of NiMH batteries for high-drain uses such as model aviation and even high-lumen flashlights). It would be nice to see measurements under load for all of the batteries (using a more suitable lithium battery -- perhaps a CR123A or a similarly-sized or larger rechargeable lithium), and results for small SLA batteries. Best regards, Charles ___ 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] OCXO Voltage Input?
Hi Bob You have some good observations. Spread spectrum clocking is one I hadn't considered when looking at this problem. In that case the crystal is pulled a bunch. (It's also cheating in my opinion!) Correcting for mechanical vibration in aircraft would also tend to indicate it's possible In the schematic for the 10544 that Tom posted the link to, it appears that when both of the EFC lines are available, only two 20K resistors are in series with the varactor. One would guess that changes on the EFC line could quite easily modulate that varactor. Assuming a similar scheme in other oscillators, one would think that modulation could quite easily happen there also. I supposed that the manual telling the operator to avoid noise on the EFC line, due to FM modulation happening, supports this theory as well! (Big Exclamation point there!) Once the question is asked, you have to ask how does one measure such a modulation? At least with simple equipment easily available. Some searching didn't result in anything promising, at least for what I have access to. Initially my thoughts are because the varactor is acting on the crystal to change frequency the assumption is the modulation is FM (Again, the HP manual backs this up). The specified peak to peak deviation is only +/- 20Hz at most. No matter what the modulating frequency is the FM modulation index is virtually zero, so there are no side bands to look for! If they are there, they are very close together. With a lack of FM side bands, one would postulate the low deviation modulation is going to look like just like phase noise. Obviously very hard to measure without a lot of good equipment. Is there a way to tease the data out, to at least get a frequency response plot by disturbing the EFC line with a signal generator? Maybe for low frequencies, a TIC and known reference could do it. It's something I'd like to test, but fear it requires more equipment than is easily available. The other thought which you brought up is spread spectrum. If spread spectrum is taken as an example, the amplitude of the 10Mhz may change with modulation on a spectrum analyzer. It's an easy enough test to try. The bottom line is, at this point, the examples on line and provided here point towards the fact modulation can happen. Given this background information it only makes sense to keep the EFC line as clean as possible. More reading is necessary to understand what the implications are. Any other input regarding real numbers, or actual testing is very welcome! Dan Some VCXOs actually specify their bandwidth. High audio is sometimes useful. I haven't seen anything beyond that, but I'm just listening to discussions like this one. There could well be applications that use a higher frequency. One application is correcting for mechanical vibrations. This is interesting in radar used on helicopters. (They do Doppler filtering to remove clutter. The lower speed of objects that can get through the filter depends on the clock stability.) PCs often FM modulate their clocks. It's a hack to get past the FCC EMI requirements. It spreads a spike in the frequency domain into a blob with a lower peak. I think 30 KHz is typical. The PCI specs were tweaked to allow this so they probably say something about the legal frequency limit. PCs probably don't use expensive OCXOs, but that technology might get used in other applications. How do FM modulators work? ___ 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] Update on my Arduino GPSDO / NTP server - going atomic
Well, my *previous* clock was on the Mega 2560 (an AVR chip, although admittedly one with more code space and IO than usual). I made some mention of it back in 2012. It had 500ns timer granularity and no Rb (just DPLL of a timer running off of the onboard crystal) but it still managed well enough :) On Fri, Sep 5, 2014 at 8:34 PM, Chris Albertson albertson.ch...@gmail.com wrote: On Fri, Sep 5, 2014 at 2:28 PM, Ryan Stasel rsta...@uoregon.edu wrote: Cool idea though. I've found very few (none) instances of people actually running NTP servers from arduino hardware... most use Raspi or the like. Note the Arduino Due has an ARM based CPU inside. It's not jet the old AVR chip. It is more than enough for NTP. Arduino is now a WIDE range of products all the way for from this is the tiny $3 Chinese versions. -- Chris Albertson Redondo Beach, California ___ 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] Update on my Arduino GPSDO / NTP server - going atomic
I was wondering if a board like the udoo would help your ntp performance. I have one and would be willing to try this configuration. Have you posted your source? I think I got confused as to who was doing this. I don't have a rubidium but I have a 6T on a breakout and a couple of very good ocxo's (mid 10-13 at 1s) that I could use. I have about 100 projects going on but a project like this has been on the back burner for awhile. I have a couple of furies I could test it against also. Bill Sent from my iPad On Sep 5, 2014, at 2:07 PM, Andrew Rodland and...@cleverdomain.org wrote: After some productive work, and some frustrating weeks spent fighting weird flakiness and needlessly replacing components, only to find that the problems went away after I reseated my main power connector, IT WORKS! Here's where I am now: * Main board: Arduino Due (ATSAM3X ARM Cortex-M3 CPU @ 84MHz) * Oscillator: Symmetricom X72. * GPS: Trimble Resolution T with a cheap Gilsson puck antenna. * Ethernet: Wiznet W5100. The X72 is used to externally clock one of the ARM's hardware timer/counters at 10MHz (I'm not multiplying it up and using it to clock the CPU). The same timer timestamps the rising edge of the PPS using capture mode, jitter free @ 100ns resolution. All the PLL is done digitally using these values and the adjustment is sent to the X72 over serial (DDS, 2 ppt resolution). After about a day's solid running, the PPS phase stays within +/- 100ns as measured on the board itself, even out to a PLL tau of 1 hour, and the frequency adjust stays within 1 ppt when 5-minute averaged. I'm collecting data against an outside reference now (PPS generated by the board against the PPS of a Spectracom NetClock with OCXO option). Too early for graphs, but it looks good. On the Ethernet end, things are less good, but still respectable -- about 10us RMS added jitter. I think a lot of this is introduced by the W5100, and I'm working on getting my hands on a board that uses the same chip but actually makes use of the onchip Ethernet MAC that the Arduino doesn't bother to route, which should help substantially. Already it's better than conventional wisdom says NTP gets :) Questions I still have: 1. Should I try using the analog EFC to zero out the amount of correction I ask the X72's DDS for? Could reduce jitter in the timebase, could just add noise. I suppose I can test this one easily enough. 2. Is there any point in decoding the sawtooth correction from the GPS, or in wiring up the PICTIC and using it to measure the GPS offset more accurately, when my clock granularity is 100ns anyway? I suppose at best I'd be improving my accuracy from +/- 1.5 ticks to +/- 0.5 ticks. 3. Anything else I should consider? If anyone is curious, code is at https://github.com/arodland/Due-GPS-NTP-Server . Thanks for following, Andrew On Tue, Jul 29, 2014 at 12:42 AM, Andrew Rodland and...@cleverdomain.org wrote: Hi all, After a couple years not doing anything except letting it sit in my den and provide time for my home network, I've decided to start hacking on my hobby project again. For reference, what I've got right now is a Freetronics EtherMega (ATMega2560-based Arduino clone with integrated W5100 ethernet), wired up to a USGlobalSat ET-318-02 (a pretty cheap consumer SiRF-III module). It runs totally custom timekeeping, PLL, and NTP protocol code. The timebase is the onboard crystal, which I have no way of influencing directly, so it basically does DDS, adding or duplicating the occasional tick to keep lock. For such a ramshackle collection of equipment it does a pretty good job, tracking within around 10us of a Spectracom NetClock (and showing less Ethernet-induced jitter than the NetClock itself) I've been thinking for years about building a next-gen version, and sketched a few designs, but I could never quite find a board that I wanted to use as the core of it. Well, Freetronics sent me a product announcement for their EtherDue board (built around the ATSAM3X, which is an ARM Cortex-M3 chip from AVR), I read some specs, and decided to dive in. I've got a working, tuned-up LPRO-101, and I always figured that my next build would desolder the clock crystal and use the Rb as the CPU timebase, like most builds I've seen do. But I realized that the ATSAM3X is happy to run its timer/counters off of an external clock as long as it's less than 1:2.5 the CPU clock. 10MHz fits that bill. I lose a little bit on granularity by not letting the CPU multiply that up 8x for me, but probably no real change in accuracy. Just feed the Rb to a pair of pins and get a register that counts up every 100ns, seems simple! For locking to the PPS I could do the usual thing and use input capture on the timer clocked by the Rb, which would handily timestamp the rising edge of the PPS. But I have a couple of PICTIC IIs laying around, and I'm a bit
Re: [time-nuts] OCXO Voltage Input?
This topic comes up every few years. I found an interesting thread back in late 2006. Typical EFC frequency response (bandwidth) of a OCXO https://www.febo.com/pipermail/time-nuts/2006-December/022758.html -- 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.
