Hello,

The 1pps signal on a M12+ is switchable. It can be selected to be on all
time or on only when tracking at least one satellite.

Regards,

Javier, EA1CRB

David Kirkby wrote:

Javier wrote:

Is turning off the 1pps, the best thing to do if controlling a crystal
or rubidium? It seems most logical to me, so I can't understand why the
default is to not to.

David Kirkby

--
David Kirkby,
G8WRB

Please check out http://www.g8wrb.org/
of if you live in Essex http://www.southminster-branch-line.org.uk/

David Kirkby wrote:

I suppose they leave it on because if they turned it off, your GPS disciplined
wall clock would stop.  If they leave it on, the wall clock would drift off time
by a few fractions of a second, and then be corrected when the signal returns
some short time later.

Just a guess,

-Chuck

Hi all,

whether turning off the 1pps with no gps reception is a good idea or not
depends completely on the electronics that actually uses the 1pps for
steering. If (and only if) it is intelligent enough to identify this
condition as being a indication for no reception and falls to holdover,
then it is a good idea. Because Motorola could not know in advance what
tricky things you would put behind their receiver they cannot be blamed
for not making it a default!

If you want to play a save game, never (i.e. NEVER) use the 1pps alone.
Always check the serial TRAIM messages for validity of the 1pps. Once
you hooked up anything that can understand the receiver's serial
messages, you should seriusly question yourself if you do not want to
use the sawtooth correction value in the steering loop. Most GPDO
designs seem not to use the sawtooth correction value despite of its
extreme wealth.

Regards

Ulrich, DF6JB

In message 42CCF7AD.8070100@onetel.net, David Kirkby writes:

part of the @@En command controls this.  You can (from memory)
have the PPS on always, when at least one sat in view, when RAIM
is happy or off.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hi David:

The older Motorola GPS receivers did not implement the Time RAIM
function and so had the 1 PPS output on all the time so I expect that's
the default for the M12T+.

I tried using Time RAIM to turn off the 1 PPS output and it does work,
but it will not work with just one satellite, there is a trade off
between how big a Time RAIM error you allow and the number of satellites
being tracked.

My thought was that if the GPS 1 PPS is used as the start signal to a
time interval counter then when it gets turned off the counter just will
not start.  If the local oscillator is the counter start then when the 1
PPS is off the counter will count for more than 1 second and the final
output when the 1 PPS starts again will be in error.

When I first tried it the 1 PPS stopped completely since my elevation
mask angle is set to 50 degrees to get rid of multipath problems.  So it
does not work for me, but would for someone who can use a lower
elevation mask angle.

73,

Brooke Clarke, N6GCE

w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com

David Kirkby wrote:

From: David Kirkby david.kirkby@onetel.net
Subject: Re: [time-nuts] 1pps signal presence with no GPS signal.
Date: Thu, 07 Jul 2005 14:06:36 +0100
Message-ID: 42CD28DC.2020906@onetel.net

Turning of the internal PPS is a crude way to say "no signal" compared to
having it read of the GPS kit. Also, if it is not turned on normally, then the
design might not be done for it either. So, it boils down to how your locking
scheme works. For some very simple schemes, loosing the PPS is worse than the
wrong PPS.

Cheers,
Magnus

Ulrich Bangert wrote:

Indeed, however there are a  number of products out there that do, and in
theory they offer 1uS precision, but many astronomers have found out the
hard way that errors can be large with using the raw 1PPS from GPS.

Although discussion is currently with the Motorola family, there are those
of us tinkering with trying to get 'cheap' cost effective timing, using more
primitive GPS modules.

A few years ago I was involved in a project to track down why certain GARMIN
modules would drop the 1PPS. We even discovered a fault with the Garmin "16"
that its little brain can get so over worked trying to regain FIX, that it
'forgets' to control its own hardware resulting in 50 Hz bursts on the 1PPS.
Some astronomers have had errors of up to 40 seconds (a long way from 1uS).

Readers may be interested in a wee project I have developed that uses a
microcontroller to extract the time from GPS and create video text all in
one $2 chip - as per:

http://www.geocities.com/kiwi_36_nz/kiwi_osd/kiwi_osd.htm

However my definition of 'precision' is about 10e10 different to the one
'tvb' would use ;-)

Regards, Geoff (New Zealand).

Magnus Danielson wrote:

I take the point made by yourself and others that whether to turn on or
off the 1pps is better depends on what you are syncing to and how the
syncing is done.

In my case, I intend locking two items to 1pps.

a) PRS10 rubidium from Stanford.

b) HP 10811A via the Bruce Shera board.

As far as I can tell, the PRS10 will not update the rubidium's frequency
unless the 1pps is present, so it would seem to me the PRS10 would
benefit from no 1pps signal rather than the wrong one. But perhaps I am
wrong.

In the case of a 10811A via the Shera board, I am less sure.

--
David Kirkby,
G8WRB

Please check out http://www.g8wrb.org/
of if you live in Essex http://www.southminster-branch-line.org.uk/

From: David Kirkby david.kirkby@onetel.net
Subject: Re: [time-nuts] 1pps signal presence with no GPS signal.
Date: Thu, 07 Jul 2005 23:59:35 +0100
Message-ID: 42CDB3D7.7090406@onetel.net

Exactly. You have to think system-wide and not only component-for-component.
If you want a system that gives you good timing, you also need to care about
the failure modes and how those could have reduced effect on your stability
and functionality. The more detailed info one could get, the better judgement
one should be able to get. Getting a good set of state information from the
GPS receiver should certainly be a good start. I should read up on the
Motorola kit.

A bad implementation (we are talking really bad in this context) will have the
phase detector flooring it, it will naturally start emptying the loop filter of
"good" state and the frequency control will eventually flooring it too and you
get the uncompensated drift of the oscillator, plus the frequency error of the
floored DAC as well as the now uncompensated noise of the DAC reference and
oscillator power. The later is normally suppressed by the locking loop. This
noise can be rather significant. So, you loose both traceability and stability.

A good design can actually give you higher stability (mid-term) by temporary
drop the traceability from the GPS. Naturally, the long term stability is the
traceability so the forced hold-over is a rather short period anyway. Short-
term stability (jitter) is really due to the oscillator.

I assume you mean the Brook Shera board from A & A Engineering:
http://a-aengineering.com/gps.htm
http://www.rt66.com/%7Eshera/

I think you are right. As I recall it, it stops learning from lack of PPS.
As always, stop assuming and know instead.

I scanned the article, but no real clue. However, if it is missing, it should
be a small feat to fix the PIC code to do it properly. Basically, lack of PPS
within say 1.5 sec of the last one means go into hold-over state. When in
hold-over state just keep the same DAC value. If you are fancy, you do more
(the HP SmartClock technology is neat since it will actively compensate for
perturbations in environmental variables etc to predict the trimming needed,
which is cool).

Cheers,
Magnus

Magnus Danielson wrote:

Yes, sorry, I meant Brook and not Bruce.

I'm pretty sure that is correct, but will double-check the Stanford
manual. But that was how I understood it.

There's a pdf on the web by the way.

Although I will have to double check, I believe with no pps input, the
DAC voltage remains fixed, so the voltage applied to the EFC input on
the 10811A will be fixed.

Incedentely, when I changed the register value on the M12+ timing
receiver to stop the 1pps output if there is no lock, it still produces
it for about 5 seconds after the antenna is disconnected. But given the
time constants used in the control loops are likely to be hours, a few
seconds will have no significant effect I would guess (although I have
not sat and worked it out carefully).

Em, that is being clever. I think I'll just stick to removing the 1pps
output if there is no lock. I've not read much about TRAIM, but I assume
that is better than relying on locking to at least one satellite, since
it will exclude any that are significantly different from the others.
Although the Motorola manual suggests the reliability is such that a
false error will occur once every 5.6 days (or some number similar to
that), which hardly sounded too good to me. I need to understand a bit
more about this.

PS,
A couple of suggestions on how I think the Synergy SynPaQ III could be
improved, if people choose to mount it inside another enclosure.

1. Allow some decent method of securing the unit inside another box.

I have no doubt voided my warranty by drilling and tapping the case with
a couple of M3 threads, so it can be secured from underneath. It seemed
better than making up brackets, or cable ties.

2. Have some method of bringing the drive to the LEDs out of the box, so
   they can be replaced by LEDs on a front panel. I'd like to get the
   1pps LED to a front panel, but short of soldering wires onto the PCB,
   that is not possible. I might either use a light pipe, or use the 1pps
   output and put it into a pulse stretcher, so it can drive an LED on a
   front panel. I'm not sure of the speed of a 555 timer, but I suspect
   that will do the job of stretching the pulse to something that is
   reasonable for an LED. But it would make life a lot easier if those 4
   LEDs could be bought onto a front panel with not too much hassle.

David Kirkby

--
David Kirkby,
G8WRB

Please check out http://www.g8wrb.org/
of if you live in Essex http://www.southminster-branch-line.org.uk/

From: David Kirkby david.kirkby@onetel.net
Subject: Re: [time-nuts] 1pps signal presence with no GPS signal.
Date: Sat, 09 Jul 2005 03:15:24 +0100
Message-ID: 42CF333C.2030101@onetel.net

OK.

Better safe then sorry.

Scanned as in read quickly through (the PDF), sorry for the confusion.

Which is sufficiently smart in this case.

Depends on the amplitude of the error. It's a linear filter after all.
I would not assume that the time constant is in hours, not for a crystal
oscillator at least, maybe for rubidium. But I agree, if the M12+ dead-counts
out a few PPSes, those where from the latest learning it did, so unless it
severly screws its PPS you are unlikely to be offset by very much.

If you have aquired a fixed physical location for the receiver, only one
visible GPS satelite would actually suffice to keep your time updated. Normally
you need to see 4 satelites to have 3 dimensions of receiver space and time
measured and estimated.

If you want to be a bit more advanced, you would use the receivers estimate of
positional error as an input to the continously running Kalman filter. Kalman
filters excell over PLLs in acheiving stable locks (as in creating a lower
ADEV curve on the output of the locked oscillator).

Good point.

A 10-pin header connector would solve alot it seems.

Cheers,
Magnus

David Kirkby wrote:

Well you could use some sleeving to attach photo transistors on the
existing LED's and use
that to drive your front panel LED's. Kinda haywire but you don't have
to modify a board.
Think of it as a electronic light pipe.

Bill K7NOM

Bill Janssen wrote:

I did modify the case by drilling/tapping a couple of holes to mount the
box, but do not intend modifying the PCB to get some light out.

The photo transistor or photo diode plus an LED is certainly one way out.

However, having thought about it more carefully, 3 of the 4 LEDs could
probably be driven from the 9-pin RS-232 port on the box, without the
need for an optical detector. The 1pps appears on pin 1, the TXD on pin
2 and the RXD on pin 3, with pin 5 common. I assume just using those
lines to switch a transistor would work fine - it might even be possible
to drive a low current LED directly with a resistor.

I'm not sure about the DIFF LED though. That might be possible to get
from the connector on the front, although I am not using that at all,
and the LED has never lit.

So I think my critisism about the LEDs was unfair, although I still
think it could benefit from a better method of mounting it.

--
David Kirkby,
G8WRB

Please check out http://www.g8wrb.org/
of if you live in Essex http://www.southminster-branch-line.org.uk/

In message 42CFA26E.4060007@onetel.net, David Kirkby writes:

Let me just insert a caution here:  RS-232 ports are heavily EMI protected
and therefore the flanks of the signal are pretty slow already.  If you
add further load to the signals you will make the slopes even worse
and therefore get even more jitter on your PPS signal.

In the first GPS I got from Synergy there was a capacitor from the PPS
signal to GND that reduced the slew-rate to less than 1V/us, but I
hope I managed to persuade them to remove it in subsequent versions.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

From: Bill Janssen billj@ieee.org
Subject: Re: [time-nuts] 1pps signal presence with no GPS signal.
Date: Fri, 08 Jul 2005 21:37:27 -0700
Message-ID: 42CF5487.9040206@ieee.org

Bill, David,

Rather, think of it as an opto-coupler, with all the benefits in isolation that
a true timenut wishes to acheive.

A 50 Hz jumping into the control-loop will be above the PLLs bandwidth and will
not be steered out by the PLL, so it will go fairly undisturbed to the output.
Fortunatly, the higher frequency the higher amplitude is needed due to the
fundamental -6 dB slope of the oscillator.

Cheers,
Magnus