[time-nuts] Is this ocxo salvageable?
My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg -- 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] Is this ocxo salvageable?
The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ 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] Is this ocxo salvageable?
On Wed, Apr 9, 2014 at 8:58 AM, David McQuate mcqu...@sonic.net wrote: The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. I agree, I had a similar problem on an oscilloscope input some time ago. It was a cold solder joint. It must definitely repairable as long as the shielding can be opened safely. Regards Frank IZ8DWF Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ 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] Is this ocxo salvageable?
I would agree with David. Or there is a SMT resistor or cap that is broken. As to opening the can, do you have a vacuum desoldering station? I usually use a good iron the heat the seam and at the same time suck out as much solder as possible. Then use a small flat blade screwdriver to pry apart the seam. You just want the seam to fail as you work it all the way around. The main point is to get as much of the solder out as possible. Take some pictures so we can see how it goes. Good luck, Tom - Original Message - From: David McQuate mcqu...@sonic.net To: time-nuts@febo.com Sent: Wednesday, April 09, 2014 2:58 AM Subject: Re: [time-nuts] Is this ocxo salvageable? The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ 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] First success with very simple, very low cost GPSDO, under $8
hol...@hotmail.com said: I'm not sure how the Arduino environment handles interrupts, but in C you need to declare any variables altered by an interrupt as volatile so that the compiler optimization routines know not to assume they contain known values. Good point. Also any code that accesses them needs to do so with interrupts turned off... otherwise you can wind up with corrupted values. Not quite. That may be the simplest way, but you can also use inter-process communications type tricks. The classic for a two byte counter is to read high-low-high and try again if the high values don't match. That assumes the interrupt routine updates low then (maybe) high. -- 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] Is this ocxo salvageable?
Two other suggestions to open the can. If you don't have a good 'suction' de-soldering station, you can try to 'wedge' some de-soldering braid in the seam to absorb the solder then proceed as Tom suggests. Also, if there is a way to 'grab' the can or the base, such as placing it in a vise, you can use a propane torch to heat the seam rapidly while pulling on the other end with a large pair of pliers. That's how I have opened HV power supplies on 5061 CS Beam Standards. They are not SMT but have a layer of thick paper wrapped around the assembly between the can and the assembly and were unharmed in the process. Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Miller Sent: Wednesday, April 09, 2014 2:33 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Is this ocxo salvageable? I would agree with David. Or there is a SMT resistor or cap that is broken. As to opening the can, do you have a vacuum desoldering station? I usually use a good iron the heat the seam and at the same time suck out as much solder as possible. Then use a small flat blade screwdriver to pry apart the seam. You just want the seam to fail as you work it all the way around. The main point is to get as much of the solder out as possible. Take some pictures so we can see how it goes. Good luck, Tom - Original Message - From: David McQuate mcqu...@sonic.net To: time-nuts@febo.com Sent: Wednesday, April 09, 2014 2:58 AM Subject: Re: [time-nuts] Is this ocxo salvageable? The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Is this ocxo salvageable?
Totally agree with the comments here. Lot of heat and I slip an exact o knife in to gently separate the can and base and also to gently lift the base out. Remember solder follows the heat so if you can tip the can apply the heat below and the solder will tend to drip out. The great news is since the oscillator is bad nothing to loose by trying to get in. Regards Paul. WB8TSL On Wed, Apr 9, 2014 at 8:01 AM, J. L. Trantham jlt...@att.net wrote: Two other suggestions to open the can. If you don't have a good 'suction' de-soldering station, you can try to 'wedge' some de-soldering braid in the seam to absorb the solder then proceed as Tom suggests. Also, if there is a way to 'grab' the can or the base, such as placing it in a vise, you can use a propane torch to heat the seam rapidly while pulling on the other end with a large pair of pliers. That's how I have opened HV power supplies on 5061 CS Beam Standards. They are not SMT but have a layer of thick paper wrapped around the assembly between the can and the assembly and were unharmed in the process. Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Miller Sent: Wednesday, April 09, 2014 2:33 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Is this ocxo salvageable? I would agree with David. Or there is a SMT resistor or cap that is broken. As to opening the can, do you have a vacuum desoldering station? I usually use a good iron the heat the seam and at the same time suck out as much solder as possible. Then use a small flat blade screwdriver to pry apart the seam. You just want the seam to fail as you work it all the way around. The main point is to get as much of the solder out as possible. Take some pictures so we can see how it goes. Good luck, Tom - Original Message - From: David McQuate mcqu...@sonic.net To: time-nuts@febo.com Sent: Wednesday, April 09, 2014 2:58 AM Subject: Re: [time-nuts] Is this ocxo salvageable? The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ 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 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] Is this ocxo salvageable?
One other tip. If the can and base are tight fitting you can file through the corners of the can at 45 degrees to the sides. This breaks the stiffness of the can and allows the sides to be folded out slightly. Straighten them before re-assembly. You can build up the corners with solder to restore the original profile. Robert G8RPI. From: paul swed paulsw...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, 9 April 2014, 14:04 Subject: Re: [time-nuts] Is this ocxo salvageable? Totally agree with the comments here. Lot of heat and I slip an exact o knife in to gently separate the can and base and also to gently lift the base out. Remember solder follows the heat so if you can tip the can apply the heat below and the solder will tend to drip out. The great news is since the oscillator is bad nothing to loose by trying to get in. Regards Paul. WB8TSL On Wed, Apr 9, 2014 at 8:01 AM, J. L. Trantham jlt...@att.net wrote: Two other suggestions to open the can. If you don't have a good 'suction' de-soldering station, you can try to 'wedge' some de-soldering braid in the seam to absorb the solder then proceed as Tom suggests. Also, if there is a way to 'grab' the can or the base, such as placing it in a vise, you can use a propane torch to heat the seam rapidly while pulling on the other end with a large pair of pliers. That's how I have opened HV power supplies on 5061 CS Beam Standards. They are not SMT but have a layer of thick paper wrapped around the assembly between the can and the assembly and were unharmed in the process. Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Miller Sent: Wednesday, April 09, 2014 2:33 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Is this ocxo salvageable? I would agree with David. Or there is a SMT resistor or cap that is broken. As to opening the can, do you have a vacuum desoldering station? I usually use a good iron the heat the seam and at the same time suck out as much solder as possible. Then use a small flat blade screwdriver to pry apart the seam. You just want the seam to fail as you work it all the way around. The main point is to get as much of the solder out as possible. Take some pictures so we can see how it goes. Good luck, Tom - Original Message - From: David McQuate mcqu...@sonic.net To: time-nuts@febo.com Sent: Wednesday, April 09, 2014 2:58 AM Subject: Re: [time-nuts] Is this ocxo salvageable? The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ 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 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] Is this ocxo salvageable?
I recently discovered that the 'square' wave from the oscillator was not looking right. I thought things were awry until I terminated the coax from the oscillator to the 'scope. Then it looked good. What probe are you using? If you are connecting from the oscillator to the 'scope via a piece of coaxial cable, you need to terminate it properly. If you are using a high impedance probe, my comments do not apply. Bob On Wednesday, April 9, 2014 5:58 AM, paul swed paulsw...@gmail.com wrote: Totally agree with the comments here. Lot of heat and I slip an exact o knife in to gently separate the can and base and also to gently lift the base out. Remember solder follows the heat so if you can tip the can apply the heat below and the solder will tend to drip out. The great news is since the oscillator is bad nothing to loose by trying to get in. Regards Paul. WB8TSL On Wed, Apr 9, 2014 at 8:01 AM, J. L. Trantham jlt...@att.net wrote: Two other suggestions to open the can. If you don't have a good 'suction' de-soldering station, you can try to 'wedge' some de-soldering braid in the seam to absorb the solder then proceed as Tom suggests. Also, if there is a way to 'grab' the can or the base, such as placing it in a vise, you can use a propane torch to heat the seam rapidly while pulling on the other end with a large pair of pliers. That's how I have opened HV power supplies on 5061 CS Beam Standards. They are not SMT but have a layer of thick paper wrapped around the assembly between the can and the assembly and were unharmed in the process. Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Miller Sent: Wednesday, April 09, 2014 2:33 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Is this ocxo salvageable? I would agree with David. Or there is a SMT resistor or cap that is broken. As to opening the can, do you have a vacuum desoldering station? I usually use a good iron the heat the seam and at the same time suck out as much solder as possible. Then use a small flat blade screwdriver to pry apart the seam. You just want the seam to fail as you work it all the way around. The main point is to get as much of the solder out as possible. Take some pictures so we can see how it goes. Good luck, Tom - Original Message - From: David McQuate mcqu...@sonic.net To: time-nuts@febo.com Sent: Wednesday, April 09, 2014 2:58 AM Subject: Re: [time-nuts] Is this ocxo salvageable? The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ 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 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] Is this ocxo salvageable?
get beryllium-coper shimming, 0,08mm or thinner--it does not get wet from the fluid solder and it is very hard, but bendable --and push it slowly, but with forcefully into the thin gap between the soldered parts to be separated, while you are heating the case from outside to keep the solder melted it is safe and does not need to overheat or pry anything, you will need multiple peace for every site of the box 73 KJ6UHN Alex On 4/9/2014 6:04 AM, paul swed wrote: Totally agree with the comments here. Lot of heat and I slip an exact o knife in to gently separate the can and base and also to gently lift the base out. Remember solder follows the heat so if you can tip the can apply the heat below and the solder will tend to drip out. The great news is since the oscillator is bad nothing to loose by trying to get in. Regards Paul. WB8TSL On Wed, Apr 9, 2014 at 8:01 AM, J. L. Trantham jlt...@att.net wrote: Two other suggestions to open the can. If you don't have a good 'suction' de-soldering station, you can try to 'wedge' some de-soldering braid in the seam to absorb the solder then proceed as Tom suggests. Also, if there is a way to 'grab' the can or the base, such as placing it in a vise, you can use a propane torch to heat the seam rapidly while pulling on the other end with a large pair of pliers. That's how I have opened HV power supplies on 5061 CS Beam Standards. They are not SMT but have a layer of thick paper wrapped around the assembly between the can and the assembly and were unharmed in the process. Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Miller Sent: Wednesday, April 09, 2014 2:33 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Is this ocxo salvageable? I would agree with David. Or there is a SMT resistor or cap that is broken. As to opening the can, do you have a vacuum desoldering station? I usually use a good iron the heat the seam and at the same time suck out as much solder as possible. Then use a small flat blade screwdriver to pry apart the seam. You just want the seam to fail as you work it all the way around. The main point is to get as much of the solder out as possible. Take some pictures so we can see how it goes. Good luck, Tom - Original Message - From: David McQuate mcqu...@sonic.net To: time-nuts@febo.com Sent: Wednesday, April 09, 2014 2:58 AM Subject: Re: [time-nuts] Is this ocxo salvageable? The output looks differentiated, as would happen if the wire connecting the internal circuit to the output pin became open, leaving only a very small capacitance to couple the square wave out. Dave On 4/8/2014 11:46 PM, Chris Albertson wrote: My Bliley square wave 10MHz OCXO was working just fine for close to 30 hours until a few hours ago. Now it puts out a rather noisy waveform about one volt peak to peak. Two questions: (1) Are these things repairable, the metal can is soldered. (2) As you can see in the attached oscilloscope photo the OCXO still puts out a strong 10MHZ component. What is the best way to filter this and recover a good 10MHZ square wave? In the linked photo, both channels are set to 1 volt per division. The large sine wave is from a Trimble Thunderbolt and the smaller wave is from the failed ocxo The EFC is left open (disconnected) and a you can see the frequency is spot on 10MHz. https://www.dropbox.com/s/0gy3yobd4myi4vp/waveform.jpg ___ 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 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] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray hmur...@megapathdsl.net wrote: hol...@hotmail.com said: I'm not sure how the Arduino environment handles interrupts, but in C you need to declare any variables altered by an interrupt as volatile so that the compiler optimization routines know not to assume they contain known values. Good point. Also any code that accesses them needs to do so with interrupts turned off... otherwise you can wind up with corrupted values. Not quite. That may be the simplest way, but you can also use inter-process communications type tricks. The classic for a two byte counter is to read high-low-high and try again if the high values don't match. That assumes the interrupt routine updates low then (maybe) high. You have to read hardware counter registers on some PIC chips that way. You have to read the documentation carefully to work out how to correctly read 16bit counters on an 8 bit CPU. The order the interrupt routine updates the counter shouldn't matter since it's atomic as far as the mainline code is concerned. Orin. ___ 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] First success with very simple, very low cost GPSDO, under $8
On Tue, Apr 8, 2014 at 10:44 PM, Mark Sims hol...@hotmail.com wrote: I'm not sure how the Arduino environment handles interrupts, but in C you need to declare any variables altered by an interrupt as volatile so that the compiler optimization routines know not to assume they contain known values. Also any code that accesses them needs to do so with interrupts turned off... otherwise you can wind up with corrupted values. Imagine that the mainline code is accessing a multi-byte variable. The code accesses the lower byte, in comes an interrupt that changes the variable (new low and high bytes, then the interrupt routine returns to the mainline code), and then the mainline code proceeds to access the (now changed) high byte of the variable... the resulting value is a mishmash of the old and new values. You are 100% correct. You can read in the code I posted that all variables used in the interrupt handler are declared volatile The Arduino programming environment uses the GCC C++ compiler But I think you over looked one point that makes this project easier: We KNOW 100% for certain that the interrupts happen only once per second. So the foreground code knows for certain it has exclusive access to shared variables for a given period of time. There is zero chance of a problem in the next .999 seconds after an interrupt. I tested this for 30+ hours and no problem was detected. But yes. iff a second PPS happens just a millisecond later you have a potential problem but then t=you also have a broken GPS receiver and the GPSDO would not work no matte what you did. The test I ran sent the OCXO signal to both an HP counter and the Arduino. My spot checking over a 24 hour run showed the two agree. (I added code to display the count to an LCD screen that was physically close to the counter and just looked by eye to see that were the same, The last digitals (0.1Hz) differs by one as I would expect.) Then as maybe you read in my next post the OCXO failed. The arduino measured 0 Hz and quickly moved the DAC output to full 5 volts trying to pull the frequency back up to 10MHz from 0. My next test will be to feed a 10MHZ and PPS signals into the Arduino from a Thunderbolt. The TB signal is near perfect and I will look at the noise reported by the Arduino. Something to try while I unsolder the can. -- 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] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 9:39 AM, Orin Eman orin.e...@gmail.com wrote: On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray hmur...@megapathdsl.net wrote: The order the interrupt routine updates the counter shouldn't matter since it's atomic as far as the mainline code is concerned. In my case it's the other way around, the 16 bit counter is updated by pin-5 and it is atomic It is done in the chip's hardware. Actaully I don't care much about an off by one count because the problem is corrected in the next second. If I happen to miss a count one second the very next second this shows up as an extra count.I notice that something like this happens every few hundred seconds. The PI controller algorithm is very simple and acts as a kind of filter. It all works in integer math and the DAC is only 16-bits so this kind of error s lost between the bits. I don't care if the DAC's value is off by .04 because it can only be set on full counts. The goal was to keep the first version of the code SIMPLE. One problem I want to avoid is where I measure a board with a micrometer and then cut it with an axe. When you know you are cutting an axe, you don't even need a tape measure. Later I add some sophistication back in and measure the effect. Heck at this point I have a capacitor based TIC that I am completely IGNORING. The point is to see what each added layer of complexity buys. -- 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] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray hmur...@megapathdsl.net wrote: Also any code that accesses them needs to do so with interrupts turned off... otherwise you can wind up with corrupted values. Forgot if I made this point but in a GPSDO when the interrupt is caused by the PPS, the interrupts are in effect off for 0.9 seconds after each interrupt. The software can assume an interrupt will never happen less then one second after an interrupt. So the software does all the variable access within millisecond after each interrupt. These micro controllers are actually much easier to deal with than a general purpose multi-tasking operating system. There is far less non-determinism. -- 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] First success with very simple, very low cost GPSDO, under $8
Actaully I don't care much about an off by one count because the problem is corrected in the next second. If I happen to miss a count one second the very next second this shows up as an extra count.I notice that something like this happens every few hundred seconds. I think you can turn that into a feature. Suppose you start with the DAC/OCXO running at exactly 10 MHz, and the phasing such that you are right on. Due to noise, the last count will be early and get counted half the time. The other half of the time, it will be late and get counted in the next second. So if you don't see that sort of noise occasionally, you know you are drifting off from a phase that was right on. Have you calibrated the DAC yet? If you bump it up by 1 count, how long does it take for the OCXO to drift by a cycle? Another low cost way to get better resolution would be to use 2 counters and a delay line. Pick the length of the delay to be well above the noise level. -- 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] First success with very simple, very low cost GPSDO, under $8
But I think you over looked one point that makes this project easier: We KNOW 100% for certain that the interrupts happen only once per second. So the foreground code knows for certain it has exclusive access to shared variables for a given period of time. There is zero chance of a problem in the next .999 seconds after an interrupt. Actually, you don't know that. You know that's the way it's supposed to work, but there are all sorts of ways that things can (and do) screw up and making that sort of assumption can lead to problems that are very hard to debug. It would be interesting to compare the size and complexity of simple code that doesn't have much error checking with defensive code that checks all sorts of things. Sometimes a sanity check is a good way to explain a subtle point. -- 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] First success with very simple, very low cost GPSDO, under $8
If my one interrupt per second assumption is wrong the GPS is badly broken and nothing I can do will make the gpsdo work. In a final system I should try and detect violations of the assumption and go into hold over mode. That said I tried a test where I took the interrupt line in my hand and rubbed it on a piece of metal and triggered tens of thousands of random interrupts per second. The code works even in this case. What happens in this code is that inside the interrupt handler the ONLY thing it does is with interrupts disabled, it copies data to global variables then exits. The copy is in effect atomic. You don't see all that is happening because the Aruino environment handles some of this. It writes about 40 bytes then sets a semaphore-like bit that says in effect get it now, the foreground software spin-locks on this bit, gets the data and resets the bit. I've been know to make gross errors in software design and forget stuff but I should understand this. I've done a bit of graduate level work in computer science and worked a few years on operating system internals. In general you are correct but in this case the system is so darn simple that all the code fits on one screen and I can read the whole thing without scrolling, Ok I have a 27 screen but still there is not a lot going on here. On Wed, Apr 9, 2014 at 11:34 AM, Hal Murray hmur...@megapathdsl.net wrote: But I think you over looked one point that makes this project easier: We KNOW 100% for certain that the interrupts happen only once per second. So the foreground code knows for certain it has exclusive access to shared variables for a given period of time. There is zero chance of a problem in the next .999 seconds after an interrupt. Actually, you don't know that. You know that's the way it's supposed to work, but there are all sorts of ways that things can (and do) screw up and making that sort of assumption can lead to problems that are very hard to debug. It would be interesting to compare the size and complexity of simple code that doesn't have much error checking with defensive code that checks all sorts of things. Sometimes a sanity check is a good way to explain a subtle point. -- 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. -- 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] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 11:18 AM, Hal Murray hmur...@megapathdsl.net wrote: I think you can turn that into a feature. Suppose you start with the DAC/OCXO running at exactly 10 MHz, and the phasing such that you are right on. Due to noise, the last count will be early and get counted half the time. The other half of the time, it will be late and get counted in the next second. So if you don't see that sort of noise occasionally, you know you are drifting off from a phase that was right on. Have you calibrated the DAC yet? If you bump it up by 1 count, how long does it take for the OCXO to drift by a cycle? Another low cost way to get better resolution would be to use 2 counters and a delay line. Pick the length of the delay to be well above the noise level. I'm out of counters. The chip only has one 16-bit counter. I think I can do all the averaging and dithering using only the PI controller. The I term in effect handles dithering. When the error toggles from plus to minus I goes to zero and the DAC is not changed much. But if a few more pluses than minus happen the I term goes positive and slowly pulls the DAC up. I don't have to use if statements in the code. The effect is I see a dither between 499 and 500 which cases the DAC to move up then I see a long row of 500 samples which is the perfect count. But then I see a 500 and 501 dither which puss the DAC down and I get many more 500 samples. It mostly hangs out at 500 So I have to disagree, differing is not what I want. I want to be dead-on 500 cycles per second (that is 10MHZ after the divide by two in the 74HC390)Then as soon as I see a few 501 samples I need to very slowly go bcd down until a 499 is detected 10 or 15 seconds late. This is what is actually happening. It seems to work with no if statements. What I think I need is to fine tune the PID constants and likely have a few sets of constants. For example I find a larger I causes the system to very quickly get a lock but also the large I causes overshoot.I may implement different modes, like fast lock and best short term and best long term Maybe even have a PID auto tune mode where I measure the system response. I am only using a tiny fraction of the available space for code. There is room for many thousands more lines of C code. The line count is only a couple dozen at present. -- 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] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 1:34 PM, Hal Murray hmur...@megapathdsl.net wrote: But I think you over looked one point that makes this project easier: We KNOW 100% for certain that the interrupts happen only once per second. So the foreground code knows for certain it has exclusive access to shared variables for a given period of time. There is zero chance of a problem in the next .999 seconds after an interrupt. Actually, you don't know that. You know that's the way it's supposed to work, but there are all sorts of ways that things can (and do) screw up and making that sort of assumption can lead to problems that are very hard to debug. So create a semaphore that says who owns the variable. Or, better still, us a message-passing executive. -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8
To further Brian's comment: you have to keep in mind that the interrupt routine interrupts the mainline code, and not the other way around. So, you set a semaphore in your mainline code and your interrupt routine checks to see if that's set when it starts, or at least before it uses any variables you have protected by the semaphore. In my code, I just set a bit immediately before changing two critical variables, and reset it immediately afterward. If the interrupt routine finds the semaphore set, it returns and does nothing till next time. This prevents any question about whether the interrupt routine can update or even use the variables in question. And not that it makes any difference, but I went down much the same path as Chris is going down with my non-TIC code. Maybe Chris will find something that I couldn't find. For me, there was always something just out of reach to prevent it from working properly. That something may just be that I was using a nav receiver instead of a timing receiver. I wound up with a very accurate counter; but it was still just a counter when all was said and done. Bob From: Brian Lloyd br...@lloyd.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, April 9, 2014 3:17 PM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8 On Wed, Apr 9, 2014 at 1:34 PM, Hal Murray hmur...@megapathdsl.net wrote: But I think you over looked one point that makes this project easier: We KNOW 100% for certain that the interrupts happen only once per second. So the foreground code knows for certain it has exclusive access to shared variables for a given period of time. There is zero chance of a problem in the next .999 seconds after an interrupt. Actually, you don't know that. You know that's the way it's supposed to work, but there are all sorts of ways that things can (and do) screw up and making that sort of assumption can lead to problems that are very hard to debug. So create a semaphore that says who owns the variable. Or, better still, us a message-passing executive. -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ 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] First success with very simple, very low cost GPSDO, under $8
Another point with the software is that your handler for the PPS just reads the counter. This gives an offset between the PPS edge and the value read, as your software takes time to respond to the interrupt and read the counter. In your code, it doesn't matter as you only have one interrupt. However, if you have another interrupt enabled, this could run after the PPS pulse but before the handler runs, giving you a very rare jitter. A better way would be to use the input capture feature to read the timer into a capture register. Then the interrupt handler has until the next edge to read the capture register. Just an idea, you might be able to assign the interrupt priority for the PPS edge to a priority above all others to avoid this problem, but this is getting complex. Simpler to handle it by hardware. To debug jitter, you could make your mainline set an output line, and watch the delay between the PPS and the line on a CRO set on infinite persistance, just to check if it works. Tom Harris celephi...@gmail.com On 9 April 2014 13:05, Chris Albertson albertson.ch...@gmail.com wrote: I just had some success with a new GPSDO based very much on Lars Walenius' design I cut his design and his software down to make it even more simple and cost less. The controller is now well under $8. The software is also much simpler and easy to read even if you are not a software guy. Lars' design and software will out perform mine. There is no question on that. But my goal was to first build a VERY low cost and more importantly easy to understand and replicate GPSDO. In this first version of the GPSDO I did not implement the TIC. I only count how many cycles occur from the local oscillator between PPS pulses and then use a PI control to adjust the DAC. Performance. I am open to suggestions on how I can characterize the performance. This project is being designed for a beginner who would not have exotic test equipment. I would call the performance not as bad as you might guess. I have had the output of this GSPDP and the 10MHz signal from a Trimble Thunderbolt both up on my Tek 365 100MHz dual channel scope for about 26 hours and they seem to more or less keep in phase. The GPSDO waveform drifts one way then the other. I can see the short term stability is good only to about the E-9 level but of course being locked to a GPS it has very good long term stability. And this with about $8 worth of parts and build in about one hour. (Not counting the power supply (a plug-in wall wort type), OCXO and GPS) Also the controller software is intentionally simplified. The E-9 is an estimate. I'm looking for a good way to measure it with simple tools. Plans: I will add features and sophistication one step at a time and I will try to document the process. Even as I add more my goal is still (1) an understandable design that anyone can build with no special tools or equipment and (2) cost. With equal importance to each. The next step is too add some refinements to the software, different modes and so one. But this stripped down version will be the introduction for a tutorial on GPSDO design. Goals: I want to document this as a design others can build. Even if they are new to all of this. I also want to keep the software open and easy to modify in the hope that others will actually modify it and post their mods here for kind of peer review Parts list: 74HC390, Aruindo pro mini, two small electrolytic caps and three resisters. That's it. The Mini is $3.71 with free shipping the 74hc390 was $1. Other parts where in the junk box. A software listing is attached. I used some of Lars' code but added a few ideas of my own and removed 80% of the functionality in preference to clarity. I'm not 100% done. I know I can make if more readable. -- 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.
[time-nuts] First success with very simple, very low cost GPSDO, under $8
Well, where interrupts are involved, NEVER assume something about how the code SHOULD/MIGHT be working. It is easy enough to disable interrupts before accessing the volatile variables and restore them afterwards. This is by far the simplest and most reliable way to do it correctly (no messy message passing/semaphores/smoke signals/etc). unsigned char sreg; // variable to save the processor status register in sreg = SREG; // save current processor status register cli(); // disable interrupts in the status register // access variables here SREG = sreg; // restore original interrupt state ito the processor status register ___ 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] Clock quality: alternatives to ADEV
I've been watching the discussions and graphs for a while. ADEV seems appropriate for cases where the noise pattern is nice. How does ADEV work if the noise isn't nice? Are there alternatives? What's the mathematical term for the type of noise that works well with ADEV? I can think of 3 examples: Crystal jumps GPSDOs going into holdover. Power lines make all sorts of interesting not-quite jumps. Is there a way of characterizing that sort of event? How do I turn a pile of data into a useful graph or chart? What does an ADEV graph look like if the data has crystal jumps? I'd expect that something like crystal jumps would follow some sort of power law: the bigger jumps would be less frequent. But it wouldn't surprise me if the GPS or power lines had an underlying mechanism that turned into a different pattern. -- 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] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris celephi...@gmail.com wrote: Another point with the software is that your handler for the PPS just reads the counter. This gives an offset between the PPS edge and the value read, as your software takes time to respond to the interrupt and read the counter. In your code, it doesn't matter as you only have one interrupt. Actually there are two interrupts. One is for PPS and the other is for overflow of the 16-bit counter. This over flow happens about 76 times per seconds. However, if you have another interrupt enabled, this could run after the PPS pulse but before the handler runs, giving you a very rare jitter. A better way would be to use the input capture feature to read the timer into a capture register. Then the interrupt handler has until the next edge to read the capture register. Do you know how to do this. I don't see any way to capture the timer value other then reading it with software. The timer capture register is 16 bits and is set atomically after each timer increment but I don't see a way to make an external interrupt pin capture a timer. The two interrupts do bump into each other about roughly every 100 seconds but I can detect that. I think I'll just ignore that second. -- 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] GPS tick compared to WWVB and WWV ?
Hello to the group. Still working the wwvb d-psk-r. A long time ago I did an early experiment looking for the phase flip on wwvb. I used a GPS tick but at the time the wwvb spec was not in its final form and I never looked for the flip 100 ms from the tick. Went 25-50 ms. Kind of call it a gps assisted d-psk-r. Well I took a look at it again and its been an interesting experiment. But the first question I have do all GPS receivers essentially tick at the same time within the 1 ms range. I assume they do for both navigation and time transfer. My ublox receiver is 8.6 ms in advance of the wwvb and wwv signal and even further in advance that at what I suspect is the propagation delay through the receiver. The fluke207 is 13 ms and the HP 3586 is 14 ms late.(The HP has far more processing delay than the Fluke). If the GPS is true than to look for the phase flip you must add propagation delay + receiver delay + 100 ms wwvb delay to flip or about 118 ms from the GPS tick. Make sense? The other thing that really jumps out at me is that using the falling edge of the wwvb 60 Khz is really a very poor approach to finding the flip. As I have now measured the falling edge depending on signal levels can be 50 ms one way or another. So much for the simple cmax chips as a useful tool directly applied to the phase flip of wwvb. It can be still useful as a source of time. Regards Paul WB8TSL ___ 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] First success with very simple, very low cost GPSDO, under $8
Have you considered reading the timer only at PPS? You don't need to keep track of the actual count. You just need to keep track of the difference between counts at each PPS. Resolution isn't a problem since the difference in the lower 16 bits is a fixed number for your purpose. IOW, 10,000,000 is 0x989680. You're only interested in the 0x9680. If there's a difference in two successive timer counts of 0x9680, then you know you counted 10,000,000, unless your oscillator is capable of running at one of the other values that gives 0x9680 as the lower two bytes. Bob From: Chris Albertson albertson.ch...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, April 9, 2014 6:35 PM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8 On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris celephi...@gmail.com wrote: Another point with the software is that your handler for the PPS just reads the counter. This gives an offset between the PPS edge and the value read, as your software takes time to respond to the interrupt and read the counter. In your code, it doesn't matter as you only have one interrupt. Actually there are two interrupts. One is for PPS and the other is for overflow of the 16-bit counter. This over flow happens about 76 times per seconds. However, if you have another interrupt enabled, this could run after the PPS pulse but before the handler runs, giving you a very rare jitter. A better way would be to use the input capture feature to read the timer into a capture register. Then the interrupt handler has until the next edge to read the capture register. Do you know how to do this. I don't see any way to capture the timer value other then reading it with software. The timer capture register is 16 bits and is set atomically after each timer increment but I don't see a way to make an external interrupt pin capture a timer. The two interrupts do bump into each other about roughly every 100 seconds but I can detect that. I think I'll just ignore that second. -- 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] Yet another Arduino-based GPSDO
Looks like you took the design in the other direction. Adding more to it. My goal was to strip it to the minimum. That software looks good. I'll good into it. But in the end I want the gpsdo to work with no computer attached. It needs a tiny LCD of it's own. I just ordered a few Nokia 1 square displays for about $3 each.The free shipping option takes about 6 weeks from China. I see you used the 12-bit I2C DAC. But the cheap 16-bit Lars used is working very well. PWM works because we only need less then 1Hz bandwidth so we can filter the heck out of it.The steps are less than I can measure What TIC capacitor did you use. If it is that temperer sensitive you might want to replace it. On Wed, Apr 9, 2014 at 5:44 PM, Jim Harman j99har...@gmail.com wrote: My apologies if this posts twice. I sent a copy earlier today but I think that was before I was subscribed to the list... I have recently built a low cost Arduino-based GPSDO based on Lars Walenius' design and thought I would share my experiences. For the GPS I am using the Adafruit GPS Shield ($49.00) which is based on the Globaltop 3339 chip. This does not have a stationary mode or sawtooth compensation but it does have a 1 pps output with stability speced at 100 ns RMS. Typical performance seems a good deal better than this, using the Adafruit external antenna. My antenna is outdoors on a windowsill, so it sees about half the sky. Sawtooth is about 10 ns p-p. I was able to fit the phase comparator onto the prototyping space of the GPS Shield card. My oscillator is a surplus OCXO made by FOQ Piezo, which cost $25.00 on eBay. Drift after several days of operation is about 6x10^-11 per day. In place of Lars' PWM-based DAC I am using a 12 bit MCP4725, with an I2C interface to the Arduino. This is available on a breakout board for $4.95 from Adafruit. The oscillator, DAC, and HC393 divider are packaged separately from the GPS and phase comparator, with a 6 inch jumper between them. One advantage of this arrangement is that you can use the oscillator stand-alone. The DAC has non-volatile memory which I load with the latest 3-hour average value, so it will remember its calibration. Observations based on about a week of testing: -- Because the oscillator has only one ground pin, it is important to make sure the VCO circuitry does share a current path with the oscillator, to avoid frequency shifts when the oven current changes. . -- With the oscillator and phase detector on separate cards, I got a lot of ringing on the 1 and 5 MHZ clock lines. This added noise to the ADC readings and may have also caused occasional spurious interrupts on the Arduino. Adding 100 ohm resistors in series with these lines helped a lot. -- the 1 usec integrator at the ADC input is very sensitive to temperature. Just blowing on it causes a bump of about 75 ns, which recovers after about about 30 sec. Covering the Arduino and GPS shield to protect it from air currents improves the short-term stability considerably. -- Lars' filter, though hard (for me) to understand, seems to work very well. Dusting off my 1969 edition of Mesla and Schultz's Linear Control Systems, it appears to work like a system with lag-lead compensation. It is very handy to have independent control of the time constant, the gain, and the damping factor. -- In place of the DIP switches Lars uses to set the operating mode and time constant, I added simple commands from the PC keyboard to hold at a specified DAC value or run with the loop closed. Still to do: restore the ability to change the time constant on the fly. -- I have been using an enhanced serial monitor for the Arduino, which is very useful because it allows real-time performance monitoring and plotting. It is described here http://forum.arduino.cc/index.php?topic=185740.60 The monitor software is new and not generally released yet, but is available on request by contacting its author via the Arduino forum. This may be an answer to the issue Chris Albertson raised on how to test a GPSDO without expensive gear. You can for example produce a histogram of the 5-minute average DAC output values using just a few lines of code. You can also send messages to an Alert window, and plot the TIC and DAC values over time with a scope-like display. A screenshot that includes a hanging bridge is attached. Vertical range is 100 ADC counts (100 ns) and horizontal is 512 sec. The black trace is the raw TIC data and the red trace is TIC_ValueFiltered, the output of the low-pass filter. The blue trace is an offset version of the DAC output. The filter time constant was set to 512 seconds. The bump at about 200 sec was caused by a slight breeze blowing past the TIC. You can see the histogram window in the background. I will post schematics and my updates to Lars' code if there is interest. -- --Jim Harman ___ time-nuts mailing list
Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8
Bob, Yes, that is kind of how it works. The timer is only read once per second. After reading it we subtract whatever was the count in the previous sample to get the number of cycles in this last second. There is no accurate way to reset the timer at the start of the second. So we let it run forever. The 16-bit timer actually over flows many times per second. The maximum value it ever gets to is about 65,536. (actually 2^16 - 1)The counter will never reach 10,000,000. (but actually we count after a divide by 2 so 5,000,000 is the target number) As it turns out even in a perfect world the counter value every second is some random value between zero and 65535. Because when the overflows happen depend in the exact microsecond I applied power to the system., that is my arbitrary zero and I count up from there overflowing back to zero about 76.6 times per second Every second we capture whatever the timer value is and compute delts cycles You are right in the I don't even need data cycles. All I want is the error which is 5,000,000 minus the count. this is hopefully zero. This would be easier if we have a 32 bit counter that could be reset to zero each second. In the past I think people have built counters like this but now I can buy a $3.80 Arduino that does the counting, ADC and DAC and computer USB interface. So I put up with a harder to use 16-bit nonresetable counter On Wed, Apr 9, 2014 at 6:33 PM, Bob Stewart b...@evoria.net wrote: Have you considered reading the timer only at PPS? You don't need to keep track of the actual count. You just need to keep track of the difference between counts at each PPS. Resolution isn't a problem since the difference in the lower 16 bits is a fixed number for your purpose. IOW, 10,000,000 is 0x989680. You're only interested in the 0x9680. If there's a difference in two successive timer counts of 0x9680, then you know you counted 10,000,000, unless your oscillator is capable of running at one of the other values that gives 0x9680 as the lower two bytes. Bob From: Chris Albertson albertson.ch...@gmail.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Wednesday, April 9, 2014 6:35 PM Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8 On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris celephi...@gmail.com wrote: Another point with the software is that your handler for the PPS just reads the counter. This gives an offset between the PPS edge and the value read, as your software takes time to respond to the interrupt and read the counter. In your code, it doesn't matter as you only have one interrupt. Actually there are two interrupts. One is for PPS and the other is for overflow of the 16-bit counter. This over flow happens about 76 times per seconds. However, if you have another interrupt enabled, this could run after the PPS pulse but before the handler runs, giving you a very rare jitter. A better way would be to use the input capture feature to read the timer into a capture register. Then the interrupt handler has until the next edge to read the capture register. Do you know how to do this. I don't see any way to capture the timer value other then reading it with software. The timer capture register is 16 bits and is set atomically after each timer increment but I don't see a way to make an external interrupt pin capture a timer. The two interrupts do bump into each other about roughly every 100 seconds but I can detect that. I think I'll just ignore that second. -- 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. -- 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] First success with very simple, very low cost GPSDO, under $8
On Wed, Apr 9, 2014 at 11:03 AM, Chris Albertson albertson.ch...@gmail.comwrote: On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray hmur...@megapathdsl.net wrote: Also any code that accesses them needs to do so with interrupts turned off... otherwise you can wind up with corrupted values. Forgot if I made this point but in a GPSDO when the interrupt is caused by the PPS, the interrupts are in effect off for 0.9 seconds after each interrupt. The software can assume an interrupt will never happen less then one second after an interrupt. So the software does all the variable access within millisecond after each interrupt. These micro controllers are actually much easier to deal with than a general purpose multi-tasking operating system. There is far less non-determinism. Indeed. I was just thinking the same thing. It's much easier to deal with an interrupt routine updating variables than multiple threads fighting over them... I just had to replace a mutex lock with an atomic exchange to avoid a deadlock in my code at work. Orin. ___ 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] First success with very simple, very low cost GPSDO, under $8
You are right in the I don't even need data cycles. All I want is the error which is 5,000,000 minus the count. this is hopefully zero. Correct. Keep the counter running. No need to zero it, ever. Use differential measurements. Essentially you are using binary modulus arithmetic. This would be easier if we have a 32 bit counter that could be reset to zero each second. In the past I think people have built counters like this but now I can buy a $3.80 Arduino that does the counting, ADC and DAC and computer USB interface. So I put up with a harder to use 16-bit nonresetable counter Chris, In applications like this, never reset a counter to zero; this opens chances for off-by-one errors and cycle slips. Just compute differences. The start-up value of the timer is irrelevant. Moreover, 32-bits is unnecessary. Perhaps you didn't understand Bob's posting. Even 16-bits is more than enough. Let me explain. You only need enough bits to cover the worst case OCXO frequency drift or the worst case GPS jitter error, per second. For example, if your OCXO stays accurate to 1 ppm it can't possibly drift more than 1 us per second. Similarly, it's a safe assumption that your GPS 1PPS stays within 1 us of correct time. Therefore, the maximum number of 100 ns ticks you will be off in any second is +/-10. So even a 8-bit counter is enough. Does this make sense now? If you were building a general purpose arbitrary frequency counter, then a resetable 32-bit counter would be nice. But you're not. A GPSDO is a special case where you know the frequency will always be very close to 5 or 10 MHz every second. So you only need a few bits to measure the error each second. To use your decimal example, if the measurements are mostly 500 but sometimes 499 or 501 you only need to look at the last digit for your error. In hex this would be 4C4B40, 4C4B3F, 4C4B41, only the bottom two bits are needed (0, F, or 1). The bottom line is you don't need timer interrupts, you don't need time. You don't need 32-bits. You probably don't need 16-bits. You don't need semaphores. All you're interested in is how far off the oscillator is each second. One interrupt (for the GPS 1PPS) is all you need. If your CPU has a capture register you don't need interrupts at all. Then you don't need volatile either. Since your error is limited to +100 and -100 you can use 8-bit integers. You don't need to test for 30 hours; instead the code will be simple enough that it is air tight by design, not by luck. You will avoid interrupt collisions by not having more than one interrupt; you don't have to enable or disable interrupts either. You'll be surprised how simple it all gets. /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] Clock quality: alternatives to ADEV
Tou can try some chaos analysis on the phase space (not the phase of the signal). It may be that some kinds of shifts are chaotic. Don Hal Murray I've been watching the discussions and graphs for a while. ADEV seems appropriate for cases where the noise pattern is nice. How does ADEV work if the noise isn't nice? Are there alternatives? What's the mathematical term for the type of noise that works well with ADEV? I can think of 3 examples: Crystal jumps GPSDOs going into holdover. Power lines make all sorts of interesting not-quite jumps. Is there a way of characterizing that sort of event? How do I turn a pile of data into a useful graph or chart? What does an ADEV graph look like if the data has crystal jumps? I'd expect that something like crystal jumps would follow some sort of power law: the bigger jumps would be less frequent. But it wouldn't surprise me if the GPS or power lines had an underlying mechanism that turned into a different pattern. -- 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. -- The power of accurate observation is commonly called cynicism by those who have not got it. -George Bernard Shaw Dr. Don Latham AJ7LL Six Mile Systems LLC 17850 Six Mile Road Huson, MT, 59846 mail: POBox 404 Frenchtown MT 59834-0404 VOX 406-626-4304 Skype: buffler2 www.lightningforensics.com www.sixmilesystems.com ___ 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] GPS tick compared to WWVB and WWV ?
But the first question I have do all GPS receivers essentially tick at the same time within the 1 ms range. I assume they do for both navigation and time transfer. [] Regards Paul WB8TSL === Paul, Of the few I've tested, the PPS signal has been at the same time within the 1 microsecond range when locked, and perhaps just even within the same 100 nanosecond range (at the extremes of variation). Typically better, of course. 73, David GM8ARV -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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.
