Jumps in hi res data 02oct14

28mar13

02oct14 spectral channel jumps (top)

p2865 (Joanna) had trouble with a large number of her scans on 02oct14. The scans had a large number of pfb overflows.
Her setup:

4 mock spectrometers covering:

4 bands of 86 MHz bandwidths centered at : 1170,1420,1520,1620 MHz
64 channels, 16 bits, 480 usec sampling.
The clock was 172.032 MHz and the lowpass filter divider was 2 (giving the 86 MHz bw).
the 1120-1220 MHz and 1320 hipass filters were used.

The problem:

searching through the cima log file for the overflow messages (skipping the first part where the setup was incorrect) there were

2300 overflows b0s1g0 : 1170 band

these looked like real rfi overflows

41202 overflows in b1s1g0 1420

these were caused by bit flips in the fpga (see below).

0 overflows in b2s1g0 1520 band
401 overflows in b3s1g0 1620 band

I looked at some of these overflows and they came from an iridium satellite passing close to the beam

The fpgha bitflips in b1s1g0 mock box:

The plots show the fpga bit flips in b1s1g0 from 1000 contiguous spectra figure over plots (.ps) (.pdf)

the data comes from the first row of file:

p2865.20141002.J0417+35.b1s1g0.00200.fits

1000 spectra have been overplotted. each spectra is integrated for 480 usecs.
top frame: PolA spectra
Bottom frame: PolB spectrra
The jumps are bits flipping in the fpga.

the constant amplitude is a higher order bit flipping from 0 to 1.

Summary:

overflows were were seen in b0s1g0,b1s1g0,b3s1g0

the b0s1g0 and b2s1g0 overflows came from rfi
the b1s1g0 overflows came from fpga bitflips

The bitflips in the fpga have been seen before (more info)

This problem is intermittent.
when a 172.032 MHz clock is used and the low pass filter is used to narrow the bandwidth, these problems have occurred.
Using the 172.032 MHz clock with no decimation does not cause any problems.

The error is probably in the low pass digital filter (only used when decimating the full bandwidth).

mock diagnostics were run on 03oct14 to check for the bit flips:

the problem occurred (but not with b1s1g0).
When the clock was 168MHz or less, the problem never occurred.

Users who want to decimate the full bandwidth of the mocks should use clock frequencies of 168MHz or less

this is a parameter in the mock setup.

processing: x101/141002/rankin_lbw_proc.pro