[time-nuts] 1pps signal presence with no GPS signal.

Magnus Danielson cfmd at bredband.net
Fri Jul 8 22:40:37 EDT 2005


From: David Kirkby <david.kirkby at 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 at onetel.net>

> Magnus Danielson wrote:
> 
> > 
> >>In my case, I intend locking two items to 1pps.
> >>
> >>a) PRS10 rubidium from Stanford.
> >>
> >>b) HP 10811A via the Bruce Shera board.
> > 
> > 
> > I assume you mean the Brook Shera board from A & A Engineering:
> > http://a-aengineering.com/gps.htm
> > http://www.rt66.com/%7Eshera/
> 
> Yes, sorry, I meant Brook and not Bruce.

OK.

> >>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.
> > 
> > 
> > I think you are right. As I recall it, it stops learning from lack of PPS.
> > As always, stop assuming and know instead.
> 
> I'm pretty sure that is correct, but will double-check the Stanford 
> manual. But that was how I understood it.

Better safe then sorry.

> >>In the case of a 10811A via the Shera board, I am less sure.
> > 
> > 
> > I scanned the article, 
> 
> There's a pdf on the web by the way.

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

> > but no real clue. However, if it is missing, it should
> > be a small feat to fix the PIC code to do it properly. 
> 
> 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.

Which is sufficiently smart in this case.

> > Basically, lack of PPS
> > within say 1.5 sec of the last one means go into hold-over state. 
> 
> 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).

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.

> > 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).
> 
> 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. 

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.

> 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.

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).

> 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.

Good point.

> 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.

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

Cheers,
Magnus




More information about the time-nuts mailing list