This is a copy of the bruker script used by Shashank on one of his proteins.  It was stored at:
 /instinct1/sdeep/tbr2b_structure/hncacbf.tbr2b/2

#!/bin/csh

bruk2pipe -in ./ser -bad 0.0 -noswap -DMX -decim 24 -dspfvs 12  \
  -xN              2048  -yN                78  -zN               150  \
  -xT              1024  -yT                39  -zT                75  \
  -xMODE            DQD  -yMODE        Complex  -zMODE        Complex  \
  -xSW         7183.908  -ySW         1666.667  -zSW        10101.010  \
  -xOBS         600.080  -yOBS          60.813  -zOBS         150.890  \
  -xCAR           4.703  -yCAR         118.034  -zCAR          43.010  \
  -xLAB              1H  -yLAB             15N  -zLAB             13C  \
  -ndim               3  -aq2D          States                         \
  -out ./fid/test%03d.fid -verb -ov

DQD  for -xMODE is an alternative parameter that may be employed in the direct dimension only.
AQ_mod can be set to DQD, but it requires DIGMOD to be set to digital or homocoupling digital. This appears to be encoded in the acqu file as AC_mod = 3, DQDMODE =  0, DIGMODE=1, DIGTYPE=8

Here is a 3D processing script from Shashank's directory which is /instinct/sdeep/tbr2b_structure/hncacbf.tbr2b/2

!/bin/csh

xyz2pipe -in ./fid/test%03d.fid -x  -verb             \
| nmrPipe  -fn SOL                                  \
| nmrPipe  -fn SP -off 0.45 -end 0.98 -pow 1 -c 0.5  \
| nmrPipe  -fn ZF -size 2048                             \
| nmrPipe  -fn FT -auto                                   \
| nmrPipe  -fn PS -p0 115.0 -p1 0.0 -di               \
| nmrPipe  -fn EXT -left -sw       \
| nmrPipe  -fn POLY -auto -ord 1  \
| nmrPipe  -fn TP                                     \
| nmrPipe  -fn SP -off 0.45 -end 0.98 -pow 1 -c 0.5  \
| nmrPipe  -fn ZF -size 128                             \
| nmrPipe  -fn FT -neg                             \
| nmrPipe  -fn PS -p0 0.0 -p1 0.0 -di -verb    \
| nmrPipe  -fn POLY -auto -ord 1  \
| pipe2xyz -out data/testxy%03d.DAT -y

xyz2pipe -in data/testxy%03d.DAT -z  -verb             \
| nmrPipe  -fn ZF -pad 1                                \
| nmrPipe  -fn RS -rs 1 -sw                             \
| nmrPipe  -fn LP -before -pred 1                       \
| nmrPipe  -fn SP -off 0.5 -end 0.98 -pow 2 -c 1.0  \
| nmrPipe  -fn ZF -size 512                            \
| nmrPipe  -fn FT                                    \
| nmrPipe  -fn PS -p0 -90 -p1 180 -di               \
| pipe2xyz -out data/testxyz%03d.DAT -y

xyz2pipe and the structure ./fid/test%03d.fid are used instead of nmrPipe and just test.dat, because the bruker script will create a series of files instead of just one.  It will put them in a new directory called fid and number them test001, test002, etc.
The syntax test%03d.DAT means  (in unixese) to sequentially read files of the name testnnn where nnn is a series of digits.

The -x on the first statement means to read the data such that the dimension known as x ( the direct one) to the pulse program is still x.  To the pulse program, H was x, N was y, C was z.

The first output statement puts out a series of files as xy planes, each or any of which could be picked up by nmrDraw.
The -y option inverts x and y, or essentially undoes the transpose function (TP) so that nmrDraw will find them as H x N planes just like an HSQC, only sliced up by C coordinate.

It is possible to carry on without writing the data out and then re-reading it as above by using a ztp command (another transpose command).  However, ztp requires a lot of ram to complete without getting into a lot of disk thrashing.

Note: instinct and inept have more ram.  inept is much faster.
hinv is the unix command to find out the hardware inventory of the computer
 
 

Back to the processing script:

In the 3rd dimension, the -z switch causes the data to be reordered such that xyz = HNC becomes xyz = CHN
Thus the processing commands are applied to the C dimension.
Then on output, the -y switches x and y again to yield planes of HCN.  This is the form that Andy is accustomed
to redisplaying, to coordinate C planes with their intersections on the HSQC.

The processing steps ZF RS LP deal with a problem having to do with a manditory delay in the time of Carbon evolution before the first point can be sampled.  This, if not compensated somehow, produces very large first order phase correction, which messes up the base line.
The delay is needed because some spin echo pulse is incorporated within this time, I presume to collapse the phase dispersion of the signal in one of the dimensions.  In order to simplify processing, the pulse program adds additional delays to make the total delay to the first sample point equal to half integral numbers of the dwell time.  Dwell time is usually described as the time between taking samples of the fid in the direct dimension, and is related to sweep width.  In the indirect dimension, dwell time and sweep width are synthesized numbers coming out of the way the delays are set up to cause an fid to be synthesized in the indirect dimension.  In any case, if the delay to the first point is 1/2 a dwell time, the phase corrects are exactly -90, 180.  In this case, the delay is dependent of const1? in the pulse program.  If it is set to 1, which it nearly always is, then the delay is 1.5 dwell times.  The RS and LP are to get rid of that extra dwell time worth of delay.  ZF creates space for an extra data point,  rs shifts the data to put the extra data point at the front, and LP predicts what the data point one sampling earlier would have been based on the rest of the sample.  This restores the data to the 1/2 dwell time delay, which is handled by the phase correction.

There is an alternative method, which is to do it in the pulse program with pulses designed to cancel the effect of the delay.  That's probably what is done in the N dimension, allowing a  0,.0 phase correct as if there was no delay in acquiring the first point of the fid.

On the lock ,shim interaction with carbon decoupling issue, there is also a way to set up a function engaged by the autoshim key on the BSMS. If set up, the autoshim key will continually try to improve lock signal by tweaking specified sets of shims.  I think that would be z1.  I don't know what transverse shims would fix the rest of the problem.

With respect to using nmrDraw with the output files:
The first set is testxynnn.dat (which H x N with C unprocessed), and the 2nd set is H x C.  When loading these with nmrDraw, click the data directory, and then in the second panel the file set xy or xyz.  Then you can click through them with the z button, or in <draw> click the <2d limits> and type some specific 15N ppm value to select a slice (for the xyz set).

The first xy file is like the N plane file.  It suffers from the same insensitivity.
To get the phase right, first use a version of the first part of the processing script with /fid/test001.dat for input and using nmrPipe instead of xyz2pipe.  This is just like doing an HSQC.  Once you get the phase settings right, you can substitute them into the 3d script and let it fly.  It takes about 20 min.  I cancelled it on nmrfac and tried it on inept, but the supposed speed improvement wasn't obvious.

Result for L1orf1 p190 was disappointing.  The folded signals were essentially missing, although you could barely find a few of them peeking through the noise.  A repeat HSQC showed no loss of signal, so it's all T2 problems.  Initially Andy thought it would be OK because Shashank got an OK HNCACB when his signals were hard to see on the planes, but I checked back with Shashank and his T2's were generally 80 msec and above, whereas mine were often shorter.