[time-nuts] Telecom Solutions DCD Cesium
cfmd at bredband.net
Sun Mar 19 08:09:00 EST 2006
From: "Robert Lutwak" <Lutwak at Alum.mit.edu>
Subject: Re: [time-nuts] Telecom Solutions DCD Cesium
Date: Sun, 19 Mar 2006 07:34:43 -0500
Message-ID: <000d01c64b51$807d0930$6400a8c0 at lutwakhome>
> Monitor3 will periodically poll and save the status data to disk for you.
> See the File->Unit Monitoring Panel. It also has some very cool
> plotting/analysis features (try View->Plot). You can learn a lot about your
> unit by watching the dynamics of the boot sequence. Grab the data to disk
> with Monitor3 and go back and look at the plots.
Yes, I have alot of fancy data comming out of it thanks to Monitor3 ;O)
> The old modules were 5045, which was later renamed 4201A. Some of the last
> modules (maybe >2004) were named 4201B and had a new CsIII-based servo
> board. Also, if you get a 4201A serviced, depending on the failure, they
> may upgrade the servo to a 4201B servo board. Monitor3 can tell them apart.
> Also the servo boards have different part numbers and the new one (4201B)
> has a big Xilinx CPLD hanging off the microprocessor.
OK. I've got a 4201A, which is logical considering when it was manufactured.
> I'm not sure how much of Monitor3 will work with your older unit. I wrote
> it to work with the new CsIII-based units and later went back and cobbled in
> support for the old 5045/4201A instruments for the guys in technical
It seems to make sense (to the best of my knowledge, which I grant is limited
However, the log feature does not work. Maybe that is one of the differing
> The telemetry was originally designed to work with a dedicated
> stand-alone Sercel terminal (which has been obsolete for at least 15 years).
> The old Monitor program (which you may be able to find out there somewhere
> in cyberspace) only ran in a terminal emulator which only ran on native DOS
> machines, i.e. it wouldn't run in a DOS window under Windows, because it did
> low-level serial port control.
Well, looking at the format as I read it in the 4065 manual, I should have no
major problem writing myself a little program and parse it properly to work on
my Linux system. I don't have a Windows box except my (well, actually my
employers) laptop which I for obvious can't lock up for my time/frequency rig
> I think Monitor3's serial port control functions should work with your 5045,
> so if you get tired of 2400 baud, you should be able to crank it up to 9600
> from the System->RS232 menu.
Ah, I'll attempt that! ;O)
> In order to get the 03 alarm, you must have made it through all of the
> earlier boot sequence, so you must have plenty of signal level, good
> microwaves, etc.
That sounds re-assuring. Yes, I have assumed this too. It has acheived lock for
some shorter times.
> Without more information I would guess that your unit
> a) Problem in C-field control circuit such that DAC is demanding more
> current but atoms don't seem to respond.
> b) Short in one (or more) of the coils inside the tube so that current
> control gets to limit without locking
> c) Tube has become magnetized so the Zeeman line asymmetry is big enough
> that it tries to lock on the wrong peak.
> Watch the "Zeeman Signal Level" during boot (before it throws the alarm).
> It should be about the same as the "Clock Signal Level." If it's much lower
> (in the neighborhood of zero), than you've got no C-Field in the tube,
> either the supply is failed or the coils are shorted out (badly).
The C-field current starts of at 18 ma when it locks, then it kicks in the 05
alarm, starts regulating and finally the 03 alarm kicks in.
> If you have Zeeman Signal, next watch the "Zeeman Rabi Innovation" during
> boot. After the clock's done initializing the clock and gain servos, it'll
> try to acquire lock on Rabi Zeeman. You should see this number start
> relatively high (maybe a couple of hundred either +/-) and then you should
> see the "C-field current" and the "current-control voltage" change as Zeeman
> Rabi is driven to zero. If this succeeds, than all of your electronics (and
> most of your tube) is working fine.
> Once it acquires lock on Zeeman Rabi, it'll try to hone in on "Zeeman
> Ramsey." You'll see the Zeeman Ramsey error suddenly appear (at probably
> +/- 500 or so). Then the C-field current will keep changing to try to drive
> this one to zero. If all is well, this is the final step of lock. If the
> tube is magnetized, enough that you try to lock to the wrong Zeeman Ramsey
> peak, you will see the Zeeman Rabi Innovation start to creep back upwards as
> you hone in on (the wrong) Zeeman Ramsey. In this state, it will eventually
> kick out an 03 alarm, and possibly an 05 as well. This is typically caused
> by exposure to high magnetic fields and is fixed by degaussing the tube.
I think this is pretty exactly my problem. So, I need to degaussing the tube
then, how would you recommend me to do that? It seems pretty DIY-capable. ;O)
I will check the boot sequence like you described.
> By the way, we just finished re-writing the manuals for the CsIII and
> Cs4000. The new manuals include a new Theory-of-Operation section (by me),
> which you may find useful. It's not the same electronics as your 5045, but
> the physics and the CBT are the same. You can get the manuals off the symm
> WWW site.
Great to hear. I just pulled the 4065, CsIII and Cs4000 manuals so I got that
description. The one thing I missed in the 4065 manual was the description of
which alarms kick in when (so the mapping described problem <-> alarm was not
obvious). It is clearer with the CsIII manual.
More information about the time-nuts