HOW CAN I AVOID A RECEIVER OVERFLOW?
This is an excerpt from Varian VNMR News dated 11-18-2001.
On UNITYplus and earlier instruments, the receiver was ON by default, hence
in pulse sequences that started off with an r.f. pulse on the observe channel
on a strong sample, or whenever there is a large transverse magnetization in
the course of a pulse sequence, one could get a receiver overflow. Also
homo-gated decoupler presaturation on H2O samples would immediately generate
receiver overflow. The remedy for this was to start a pulse sequence with
"rcvroff()" (receiver off), together with a "rcvron()" (receiver on) just prior to acquisition. This avoids
receiver overflow, but leaves the amplifiers unblanked all the time, which in
long pulse sequences might lead to pulse droop and amplitude instabilities
towards the end of the sequence, which in turn could lead to bad cancellation
in experiments that do signal subtraction by phase cycling. The only (proper)
alternative on these instruments was to leave the receiver on (except around
the pulses), and to IGNORE the receiver overflow LED / message.
On UNITY INOVA, the receiver is
a) decoupled from the amplifier blanking,
Print this page.
b) OFF by default (except for the implicit acquisition, of course).
Therefore, on a UNITY INOVA...
- "rcvroff()" / "rcvron()" statements SHOULD BE AVOIDED (unless you do
explicit acquisition), and
- receiver overflow should NOT be generated during a pulse sequence. Note
that "rcvron()" at an early stage in a pulse sequence will of course still
turn the receiver on at that point and may generate receiver overflows.
- if on a UNITY INOVA you want the amplifier to be unblanked during a short
delay (to avoid long pre-pulse delays) you should use obsunblank() /
obsblank() rather then using rcvroff() / rcvron(). Note that on UNITY
INOVA, rcvron() / rcvroff() still controls BOTH the receiver gate AND the
Now stop crying and get back to work!