Date: Wed, 15 Jan 2014 14:22:53 -0500
Many thanks to: Rajan, Greg, Alan, Perry, Michael, Pat, Ryan, Andreas, Tom,
Todd, Jeff, Carlos, Martha, David, Richard, Patrick, Simon
I had 17 responses within 6 hours - MMRL is a wonderful resource!
It turned out that the problem was a 40 MHz crystal on the Junction Board.
We replaced the crystal and everything is back to normal - the spectral
artifact and lock problems were caused by the spectrometer reference
frequency shifting around during operation. Perry Pellechia (at my alma
mater) hit the nail on the head and gets the kudos for the day - his post is
below and included details on the part and it's cost.
I included everybody's responses because on another day it may not be a bad
crystal reference frequency but the lock system, shim power supply, or the
residual PFG current that many of you thought it might be. It's important to
include everybody's thought processes and approaches.
Again. Thanks so much.
Original Post and Question:
We are having an intermittent problem (once every few days) with our Varian
Mercury MVX-300 that has now become not-so intermittent (now occurs almost
every time we run a spectrum). The lock level slowly drifts downwards and
then suddenly the lock is lost for a few pulses and then it drifts back.
Pegging the lock level very high, playing with gain/power, rebooting and
power cycling the console, doesn't help the situation. When this happens a
bunch of nasty sinusoidal artifacts appear in the spectrum. Example shown
here..
Any suggestions as to what the problem might be would be appreciated. This
system does have PFG - we turned off the amplifier and removed the PFG cable
from the probe to rule out some sort of current leakage to the probe. It
doesn't seem to be related to the PFG. I have a feeling that when the lock
is lost it is caused by a drift in Z0. For a little time the problem
manifested itself as a drift in Z0, perhaps 20 DAC points, accompanied by a
large shift in lock phase. In the current manifestation the lock phase is
not changing.
The 17 answers I received:
Simon Sham: It seems to me that the lock sweep was on when the spectrum was
taken.
Patrick Wheeler: I love your example spectrum! This is a beer, no?
I recall a similar problem back when I still had a Mercury (>13 years ago,
so memory may be faulty). As I recall, we needed a new lock board. (Again,
this was a long time ago, and I haven't worked with a Mercury since.)
Have you tried running an array of s2pul with a long d1 (>20s), unlocked,
just to see what the drift is?
Richard Shoemaker: You answered my first question at the end. which is to
make sure the lock phase is correct because when you power-cycle these the
system phase-reference usually changes, which requires re-optimizing the
lock phase. It looks like you have that covered. So I only have two
quick suggestions to think about.
1) have you tried turning the lock off altogether, and acquiring the
data unlocked. We run unlocked all the time with samples in non-deuterated
solvents (and, of course, when we do solids). If the artifacts are still
there, then it eliminates the lock as being the cause of the problem.
2) This could be an instability in your RT shim supply (either a DAC
going flaky, or a current driver going bad), but since it seems to be a main
field jump, it almost has to be the Z0 coil, right?
3) Finally, this is the "out there" suggestion. nobody is doing any
arc-welding anywhere near you, are they? I had a problem similar to this
on my INOVA-400 a few years ago, and it is very frighteningly similar to
what you've shared. The lock level would be nice and stable, then bounce
down a little, crash to zero for a bit, then go back to where it was. It
took awhile, but I had my student watch down the hall where they were
welding, and every time the spark would fire-up, the lock would do its crazy
jig. The spectral artifacts were very similar to what you have shown.
After the finished the welding project (steam pipes or something), the
problem never resurfaced. Weird, huh?
Good Luck. I have a dead INOVA 500 console that is giving me fits.. you
might be seeing this one posted on AMMRL soon also. The acquisition system
has gone insane.
David Richardson: I am sorry I can't help, but I have been chasing the exact
same problem on my Mercury-Vx for a while now. Fortunately it is still
intermittent and the instrument is only used sparingly, so I haven't
invested much time tracking it down. The only small bit of useful info I
can give is that in my efforts to reproduce the issue I did notice it
happened quite often directly after gradient shimming. You seem to have
ruled out the pfg though.
Also, I recall someone messaging ammrl a year or two ago about a similar
lock phase jump and it turned out to be a degraded bnc connector on one of
the lock channel cables. Knowing the age of these consoles, it might be
worth ruling out the overly simple fix of a bad cable before delving into
more complicated things.
If you get a chance, please update me about what you discover as our
problems are probably related.
Martha Morton: Do you see the spectral artifacts if you don't lock and
actually pull off the lock cable? If you see artifacts without lock check
the decoupler. I would guess that you are loosing a clock or op amp on the
LCB board.
Carlos Pacheco: have you tried to run UNLOCKED (with lok off)?
Jeff Simpson: The ringing appears to be from the field moving whilst the FID
is being acquired. Probably unsuppressed water signal.
I would try the following experiment:
collect a large series of one-scan spectra (nt=1,1,1,1,1,1,1,1,1,1,etc) and
look for the ones that show funny behavior. If the spectrum below is one
that was from nt=16, then what you may be seeing is a superposition of the
regular spectrum and perhaps two scans that lack properly suppressed water
(I see the water signal at 4.65ppm is suppressed). That is, the field
suddenly moves, lock dips or is lost, presat no longer works, and for that
one scan you get a large water signal.
To spot the bad spectrum, type (after acquisition completes)
wft
vsadj(40)
ho=10
dss
Count up from the bottom to find the spectrum (or spectra) that do not line
up with the others.
It may be that your z0 shim is failing in the shim power supply, or perhaps
your lock receiver or lock transmitter. It also may be that your main
frequency synthesizer is failing, and so the 80 MHz timing event clock (or
whatever the clock speed is on your console) may be subject to periodic
failure. I doubt that this last possible cause is the actual problem.
You can try the same experiment running unlocked (nt=1,1,1,1, etc) and this
will tell you whether or not the feedback mechanism associated with the lock
channel is the cause. If the feedback mechanism is flawed, then shutting
off the lock and acquiring unlocked with give better results (but the
spectrum will drift around so the lines will be broader, but all by about
the same amount). If the problem persists, then the same proportion of bad
scans will be observed.
Another thing to try is a 50/50 mixture of d2o and h2o. Lock, shim, and
then turn off the lock. Run unlocked with pw=1, gain=0 with tof very close
to 4.65ppm (try tof=-104). Use the df command to display the fids
df(1)
df(2)
etc.
Use a very long acquisition time (at) so you can see if the periodicity of
the FID changes from start to finish. If the periodicity does change, that
means that the field has changed during the course of the acquisition time,
which is probably just shim power supply.
Todd Rappe: I don't know if either of these will help, but we've had issues
with unstable lock signal in recent history due to two factors:
1) Air dryer cycling - approximately every 2 minutes our lock signal would
drop and then slowly return. Putting a ballast tank in the compressed air
line between the dryer and the spectrometer solved this problem.
2) Convection - we recently had a cryoprobe installed and the engineer
forgot to increase the flow rate of the VT air to what was required for the
probe. Convection in the lineshape sample resulted in the periodic drop and
return of the lock signal making it impossible to shim. I wouldn't expect
to see this in a room temp probe, unless your sample volume is particularly
high in the tube and you are running at temps different from room
temperature. It should be easy to test, though. Increase your VT gas flow
rate and see if the behavior changes.
Tom Dickinson: What is dn set to? Try setting to a different nuclei and see
if lock is still unstable. (I'll assume it's C13)
If proper filtering isn't in place such as the BB filter or lock bandpass
filter has failed, the lock will become unsteady while acquiring and pulsing
due to harmonics.
Try setting dn to 'n' and running your proton experiment. You can also try
disconnecting the BB cable to see if the lock becomes stable again during
acquisition.
Sounds like RF interference in the probe to me due to a bad or missing
filter.
Andreas Kaerner: I guess the first question I have: Did you sparge your
mash long enough? :)
You should see if it's on the transmit or receive side of the lock. Put a
scope on the transmit side to see if it's clean or if you have a pile of
crap dumping in.
Maybe your lock xcvr board or your Z0/Z1 board is kaput. I assume this
doesn't happen when you turn the lock off. Try this, lock it and then turn
the lock power and gain to 0, but keep the lock button on. Acquire with nt
arrayed 1,1,1,1,1,1.etc. If it moves significantly (hundreds of Hz), then
your lock xcvr board is bad. Kind of chasing its tail.
I don't recall the best way to see if it's the Z0/Z1 board. You could also
try posting on Agilent's Spinsights page.
Ryan McKay: Did you try running with lock off,lock power at 0, lock gain at
0 etc?
I'm thinking you might have a wonky lock circuit and the Z0's fine.
I'd even disconnect the lock cable and try a spectra unlocked. Let me know
what happens.
Pat Hays: John this looks familiar. Check your lock phase. If lock phase
is off by more than 30 degrees you start getting funky artifacts like this.
Michael Strain: We had a seemingly similar problem on our Inova-500 which we
ended up solving by replacing the lock transceiver board. The problem might
be in the lock-sample-and-hold part of the circuitry.
I could imagine another scenario where there is poor isolation between the
lock channel and the observe channel in the probe or in the filters, e.g.
the lock trap on the 1H channel or the lock band pass filter on the lock
cable.
You might check if you get the same bevarior with the observe (and/or
decoupler) pulses set to zero power.
One more thing to check is whether the lock frequency and lock offset
calibrations are up to date. Once the sample is locked, does the lock level
stay about the same when you click "lock off" in the lock menu or does it
plummet to zero? If the latter it means that the field compensation is
working very hard and may be at a meta-stable edge of its workable range.
Is z0 near the extreme DAC setting range (probably +/- 2047 on the Mercury)?
I was just looking at your website yesterday... we have to review our NMR
user fees periodically to make sure that our "outside" rates do not unduly
compete with commercial providers of similar services. I think we're not
too far off the mark....
Perry Pellechia: We had a similar problem with a Mercury console here.
System would drop lock, and re-lock might show big phase change. A su
would bring the lock phase back. For us it turned out that the 40MHz
oscillator on the junction board was bad. The board was simple enough to
work on (not multi-layered).
Agilent had the oscillator in stock for $263 (P/N 0190344400). The
manufacturer of the oscillator (MTI) would sell me the part but they had a
$1500 minimum order and a long lead time. I ordered (2) from Agilent. We
are about to retire our Mercury systems and I would be happy to send you my
extra oscillator if you find that that is the problem.
At the time the board (New/latest P/N 190987400 was $4853 with no exchange
required or allowed) I guess they do not fix them anymore. Not sure if this
is your problem but it might be work looking at the 40MHz out put. Ours was
low but difficult to see actually fail.
Alan Kenwright: I don't think it is drift in Z0 because the rest of the
spectrum looks fine - lines are sharp, no tails on the peaks. One way to
check that would be to lock and shim a sample, then run the spectrum with
the lock cable physically disconnected. If the spectrum looks OK, then you
can be fairly sure that the problem is coming in on the lock channel. It
may be that the lock transmitter (or receiver) has gone flaky. I know that
doesn't help fix the problem, but it may help localise it.
Greg Heffron: I would suspect something in the shim power supply. The
wiggles you see are from the Z0 sweeping the field. Depending on the supply
you have, it could be called the Z0/Z1 board, but I would definitely suspect
the board that controls Z0.
Rajan Paranji: I will be really interested to know the final resolution to
this problem. But I am tempted to add this input of mine. When you see
this wiggle pattern, does it always occur at the same ppm position ? These
wiggles look pretty similar to what you will see when you record a 1H
spectrum, with the Lock mode set to 'sweep' in Bruker jargon, where the Lock
system sweeps the magnetic field over a set Lock amplitude. I am assuming
that you are presenting an 'averaged' spectrum here. If the lock system goes
'in and out' of lock mode in a periodic fashion and if this periodicity is
in rough sync with your 1D proton NMR pulsing rate, then you might be able
to record this wiggle pattern even in an averaged spectrum.
It might help if you change the recycle delay to different values and see if
the wiggle pattern shifts its position. The underlying problem though, as
already identified by you, seems to be Lock system related.
-- John C. Edwards, Ph.D. Manager, Process and Analytical NMR Services Process NMR Associates, LLC 87A Sand Pit Rd, Danbury, CT 06810, USA Tel: +1 (203) 744-5905 Fax: +1 (203) 743-9297 Cell: +1 (203) 241-0143 Skype: jcepna SkypeIn: +1 (203) 885-7458 Web: http://www.process-nmr.com Blog: http://www.nmrblog.com e-mail: john_at_process-nmr.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute, retain, or copy this e-mail or any attachments. If you have received this email in error please delete and notify the sender.
(image/png attachment: image001.png)