[time-nuts] CDMA time synch problem in Salt Lake City, UT

[Dave Andersen]

I've sent this to EndRun tech support, but since they're not around at 
the moment, figured I'd run a quick check with people on the list.  I 
don't really expect an "oh, here's your problem", but I'd love one if 
someone happens to know!

I have a somewhat older Praecis Ct (CDMA cellular time receiver) that 
seems to be having either general problems or leap second problems, or 
is locking itself to a bad CDMA station.  I'm a little baffled.

ntpdc> pe
      remote           local      st poll reach  delay   offset    disp
=======================================================================
*clock.xmission. 155.98.35.100    1   64  377 0.03848  0.664292 0.00499
=ops.emulab.net  155.98.35.100    2   64  377 0.00032  0.629554 0.00421
=GPS_PALISADE(0) 127.0.0.1        0   16  377 0.00000  0.000439 0.00023

I reset it and tried again a bit later, with more ntp servers:

=nist1.symmetric 155.98.35.100    1   64    1 0.03024  0.681881 7.93750
=clock.xmission. 155.98.35.100    1   64    1 0.03828  0.704977 7.93750
=ops.emulab.net  155.98.35.100    2   64    1 0.00037  0.683862 7.93750
*GPS_PALISADE(0) 127.0.0.1        0   16   37 0.00000  0.000297 0.43768

(top is nist1.datum.com, which I'm fairly certain is good)

Running the latest firmware from the website:

Praecis Ct FW 6010-0001-000 v 2.18 - May 25 2004 16:09:30  Praecis FPGA 
6020-0001-000 v 09

The node is located in Salt Lake City, UT, at the University of Utah.

My guess, based on the other times I've seen things like this happen, is 
either:

a)  It's synched to a CDMA base station that's running some funky 
version of the spec.  This happened a while ago when some sites upgraded 
to an early version of the CDMA2000 spec, for instance.

b)  It's synched to a CDMA base station that's just completely lost its 
clock.  Last time this happened, it was a BS that was configured with 
the wrong # of leap seconds (a few years ago, before the last one), but 
this 0.7 second offset is just weird.

Some settings and debug info from the Ct, which probably won't make much 
sense unless you've got one of these things yourself.


spstat shows:

LKD PRIB  57 212 35130  5.0 0.787

for the first, and

LKD PRIB  57 212 35128  5.8 0.029

for the second try.  (I should note that there was another one in there 
where we actually appeared to be off by .96 seconds.)

Settings on the Ct are:

Cal = +0.000000000
ChannelSet = NORTH AMERICA
Ctime = OFF
DSTStart = 0,0,0
DSTStop = 0,0,0
Emul = TRIMBLE
Event = ON (TRIMBLE)
Leap = 14 14
Lo = +0:00
Port = 9600,8,N,1
Respmode = TERSE
Tmode = UTC

and there are no "fudges" or other things applied in ntp.conf that would 
be causing the problem, as far as I can tell.

Hardware settings are:

Auxout = Ldetb
IFDiv = 0
NDiv = 29448
Agc = 212
Agc Mode = Auto
A/D Gain = 2 (High)
CarrierLock = On
CarrierPLLType = TYPE 0
EarlyLateMode = On

decoded msg is:

  TimeStamp___  Ticks  Len  Typ  Rev  MRev  Sid__  Nid__  PnO  SysTime___
Lp  Off  DST  BadCrcCount
     19088472    966   26    1    5     2     94      1   57 10474949728 
  14  -12   0   0

Leapinfo is:

CDMA system message leap second field = 14
User override settings: Override = 1, current = 14, future = 14, saved 
timetag = 837977017
Current timetag = 837996007, current leap seconds = 14, current leap 
state = OFF

Saved CDMA information is:

TimeStamp___  Nid__  Sid__  PN_  SNR_  AGC  TCXO_  LO_  DST  Leap  Len 
Type  Rev  MRev  Freq_
    837976990      1     94   57   5.4  213  35133  -12    0    14   26 
     1    5     2  PRI B
    837995243      1     94   57   6.2  212  35131  -12    0    14   26 
     1    5     2  PRI B

Any clue would be appreciated!

   -Dave