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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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.
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
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
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
32 matches
Mail list logo
