Weird GPSDO behavior
I suspect that it is either temperature related (the funkiness starts around when the temperature reaches a minimum) or related to the way the disciplining parameters are hacked to get the extended time constant. Try setting up for say a 10,000 second time constant and see how things change.
Hi
On Sep 28, 2017, at 6:59 PM, Mark Sims holrum@hotmail.com wrote:
I suspect that it is either temperature related (the funkiness starts around when the temperature reaches a minimum) or related to the way the disciplining parameters are hacked to get the extended time constant.
Like it or not, most of these devices were made back a while ago.
The CPU’s used were not the ones we have today. the code was tested
over the “expected range” of values. Most (but not all) of the control loop
code was done as integer math. With limited RAM, tossing everything into
64 or 128 bit integers was not an option. In some cases 32 bit int’s were at
a premium. Multiply this by that, that, and that. Then divide by something, and
something else. … hmmm…. a few bits just went missing. Could you reorder
and fiddle to fix some of this? Sure, that’s where we get back to the expected
range stuff.
Even if it’s not in the “main loop”, GPSDO code is full of checks for this or that.
Like the main math, they are scaled and tested for the normal range of parameters.
Not all of them spurt error messages when they get involved. Some just bump this
or that and move on.
Lots of possibilities ….
Bob
Try setting up for say a 10,000 second time constant and see how things change.
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.
Could be a delivery truck with a GPS jammer on it, that passes your
location every morning at the same time.
--- Graham
==
On Fri, Sep 29, 2017 at 7:18 AM, Bob kb8tq kb8tq@n1k.org wrote:
Hi
On Sep 28, 2017, at 6:59 PM, Mark Sims holrum@hotmail.com wrote:
I suspect that it is either temperature related (the funkiness starts
around when the temperature reaches a minimum) or related to the way the
disciplining parameters are hacked to get the extended time constant.
Like it or not, most of these devices were made back a while ago.
The CPU’s used were not the ones we have today. the code was tested
over the “expected range” of values. Most (but not all) of the control loop
code was done as integer math. With limited RAM, tossing everything into
64 or 128 bit integers was not an option. In some cases 32 bit int’s were
at
a premium. Multiply this by that, that, and that. Then divide by
something, and
something else. … hmmm…. a few bits just went missing. Could you reorder
and fiddle to fix some of this? Sure, that’s where we get back to the
expected
range stuff.
Even if it’s not in the “main loop”, GPSDO code is full of checks for this
or that.
Like the main math, they are scaled and tested for the normal range of
parameters.
Not all of them spurt error messages when they get involved. Some just
bump this
or that and move on.
Lots of possibilities ….
Bob
Try setting up for say a 10,000 second time constant and see how things
change.
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.
It makes me feel better (not good, just better) to know it's not just me...
On Sep 29, 2017 7:19 AM, "Bob kb8tq" kb8tq@n1k.org wrote:
Hi
On Sep 28, 2017, at 6:59 PM, Mark Sims holrum@hotmail.com wrote:
I suspect that it is either temperature related (the funkiness starts
around when the temperature reaches a minimum) or related to the way the
disciplining parameters are hacked to get the extended time constant.
Like it or not, most of these devices were made back a while ago.
The CPU’s used were not the ones we have today. the code was tested
over the “expected range” of values. Most (but not all) of the control loop
code was done as integer math. With limited RAM, tossing everything into
64 or 128 bit integers was not an option. In some cases 32 bit int’s were
at
a premium. Multiply this by that, that, and that. Then divide by
something, and
something else. … hmmm…. a few bits just went missing. Could you reorder
and fiddle to fix some of this? Sure, that’s where we get back to the
expected
range stuff.
Even if it’s not in the “main loop”, GPSDO code is full of checks for this
or that.
Like the main math, they are scaled and tested for the normal range of
parameters.
Not all of them spurt error messages when they get involved. Some just
bump this
or that and move on.
Lots of possibilities ….
Bob
Try setting up for say a 10,000 second time constant and see how things
change.
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.