Tests of 32-bit WAPP mode (DL/RB - Feb 6 2002)

Goal: To empirically determine the mean zero lag for 32-bit WAPP mode (summed IFs) and from this find the optimum truncation for 8/16 bit output in upcoming pulsar search experiments where relatively long sampling times (> 0.5 ms) are required.

What we did: Took WAPP data in 32-bit summed IF mode (256 lags) and found the average zero lag value for different sampling times. Prior to starting the test we took care to adjust the attenuation so that both IFs had the optimum incoming power.

As can be seen in the resulting plot of lag versus sampling time, the trend is linear (as expected!)

As can be seen from this plot, the fastest sampling rate we tried (200 us) produces a value just below the 16-bit threshold (65535). One thing to note here is that the IF sum mode does exactly that - sum the values from both channels. Dividing by 2 before writing to disk would in principle allow sampling rates as long as 400 us in 16-bit mode before overflow. This is still not a long enough sample time for Fernando's upcoming search where the goal is to dump data every ~600 us - which corresponds to values of about 183,000 on this scale. This could be stored by either bits 2-17 or, more conservatively, by bits 3-18 inclusive (bit 18 being equivalent to 256k)

What we tried next: Looked at a known pulsar for 10 s with 600 us sampling and experimented with different truncation schemes. Also looked at the CAL. PROBLEM --- we didn't have time or the right LST to look at any weak pulsars to test out the choice of bit selection thoroughly - CAL is too strong.

What is needed: Hook up the artificial pulsar so that it is a weak signal (i.e. requires an integration time of 5 minutes or more for detection). Run the WAPP in 32-bit mode and pass the resulting zero lags through a pulsar search program to yield some signal-to-noise ratio. Then repeat the experiment using the same sampling time but recording only 16 bits for different bit selections and compare the resulting signal-to-noise ratios against the original 32-bit value.

If this works as we expect: Ask Jeff to implement a feature in the WAPP to sample the zero lags and, based on the mean value, default to a sensible truncation value.