Jumps in hi res data 27mar13
27mar13 spectral channel jumps (top)
p2787 (Joanna) had trouble with one of her scans
on 27mar13. The scan had a large number of pfb overflows.
The problem was:
The first figure over plots the
spectra from the first 3 rows of the file (.pdf):
- The file with the problem: p2787.20130327.B1726-00.b1s1g0.00200.fits
- The PFB overflows were reported in
polB. Looking at the data, there were also jumps in polA (just
not as large).
- The mock setup was
- 64 channels, full stokes, 256 usec sampling, using lbw.
- 170MHz clock with 85 MHz bandwidth (divide by 2 in the
- When the digital filter is used (to reduce the bandwidth)
we have gotten these jumps in the data with higher clock
- The problem has to do with the digital filter. When the
full bandwidth is used, the jumps never occur.
The dynamic spectra show freq vs
time for the first 3 rows (polB) (.gif):
- top frame: PolA spectra
- each row had been offset by 8000 counts
- there are 3905 spectra in each row
- Bottom frame: PolB spectrra
- The jumps occurred more often in polB
- The bright dots are the jumps
28mar13: running the diagnostics:
The rdComp diagnostic was run on 28mar13 (see
. This test:
Any jumps in the data in one fpga will get flagged as errors.
Normally we see the difference as a single bit flipping.
- Uses digitally generated noise (in place of the A/D input).
This data is the same in each spectrometer.
- For each box the signal is processed by the fpga code and then
sent to the first spectrometer (pdevs1).
- Each sample from all the spectrometers is compared with the
sample from the first spectrometer. If any data value does not
match, then that data is flagged as an error.
- The test was run on all 14 spectrometers (group 0 and group
- Clock rates of 172.032, 170.00, 165.00, and 160 MHz were used
- Intermittent problems occurred at 172.032,170, and 165
- 160 MHz never failed.
- many of the failures included the box :b1s1g0 that gave p2787