Intro

    Pulsar observations with the 3GHz filter (wb3) have seen lots of rfi in the 2750 to 3450 band (filter wb3). The rfi in polB is worse than polA.
The mock system log files

• /share/p12m/Logs/Obs_logs/

Show a large number of pfb (PolyphaseFilterBank) overflows. These are the butterfly stages in the fft.
This problem occurs because:

• The xilinx chip uses 18bit registers to do the fixed point fft.
• The 12bit sampled voltages start in the upper12 bits of these registers.
  
• For a noise like signal, the ampl grows as the sqrt(Number of Adds)
• By default, Every two butterfly stages, the 18 bit registers are downshifted by one bit
• This should keep a noise like signal within range of the 18 bit register
• If a tone is embedded in the  data, then it will increase as the number of adds. Because of this, we can get overflows in the butterfly stages.
• the fpga code for the mock pfb  does not clip the 18 bit numbers when they overflow, it lets them role over
• jeff mock said it probably didn't matter since the phase was also messed up if you just clipped the amplitude.
• The spectra density is then computed from using the output of the pfb and accumulated in a 40bit register.
• pulsar observing takes 16 bits of this reg and outputs it to disc.
• When taking the 16 bits, overflows are clipped (rather than allowed to roll over).

    On 27jun23 i took some data to see if a more aggressive pfb shifting would help the rfi situation.

---

Setup:

• The 12meter receiver used the wb3 filter
• 5 mock boxes were used. Each had:
  
• 172.032 MHz bw polA,B recorded
• 16 bit spectra
• 32usec sampling
• The 5 boxes were centered at:
• 2846.152 2909.32 3050.88 3192.44 3334.0
• 2 sets of 10seconds of data was taken
• file 000: using default pfb shifting (mockset pshift noise)
• file 100: use a more aggressive shifting: (mockset pshift radar)
• 9 downshifts then alternate every other butterfly
• given a 256 length fft there are 8 butterfly stages, so each stage has a downshift.
• --> these data sets were not taken at the same time.
• So the rfi  strength, timing will not be the same for the 2 sets.
  

---

Looking at the data:

File 000 with standard pfb pshift values

• the 10 seconds of data started at 09:04:05
• The system log files show lots of pfb overflows:
• Tue Jun 27 09:04:05 AST 2023 infook  pnetg0:b2s1g0: ADC=0 PFB=1 VSHIFT=0 ACC_S2S3=0 ACC_S0S1=0 ASHIFT_S2S3=3 ASHIFT_S0S1=3
  Tue Jun 27 09:04:05 AST 2023 infook  pnetg0:b2s1g0: ADC=0 PFB=2 VSHIFT=0 ACC_S2S3=0 ACC_S0S1=0 ASHIFT_S2S3=3 ASHIFT_S0S1=3
  Tue Jun 27 09:04:05 AST 2023 infook  pnetg0:b2s1g0: ADC=0 PFB=1 VSHIFT=0 ACC_S2S3=0 ACC_S0S1=0 ASHIFT_S2S3=2 ASHIFT_S0S1=2
  Tue Jun 27 09:04:05 AST 2023 infook  pnetg0:b2s1g0: ADC=0 PFB=1 VSHIFT=0 ACC_S2S3=0 ACC_S0S1=0 ASHIFT_S2S3=2 ASHIFT_S0S1=3
• the number after pfb=n  says that there were between 2^n and 2^(n+1)  overflows during the integration.
• The ashift_s0s1=n  says that there were overflows (that were  clipped) when we took the 16 bits from the  40bit accumulator.

file 100 with the more aggressive radar shift for the pfb:

• the 10 seconds of data started at 09:05:09
• The system log files showed now overflows in the pfb
  

The first plot shows how often there were overflow errors in the two runs (.ps) (.pdf)

• black is the default noise shifting of the pfb
• red is the more aggressive radar shifting of the pfb
• Page 1: pfb overflows
• Each frame  is a different frequency band.
• the x axis is time
  
• the y axis is the number of errors (i expanded 2^N)
• There are no pfb errors with the radar shift in any band
• the 3136 band has the most pfb overflows with the noise shifting
• the 2 second increases are probably the 2 second rotation period of the radar in the band.
• Page 2: overflows when selecting the 16 bits from the 40 bit power  accumulator.
• frames 1-2  : band 2760 to 2932
  
• top noise shift
• 2nd:  radar shift
• they both have overflows when selecting the 16 bits
• frames 3-4 the 2964 to 3136 band
• this has lots of overflows probably driven by the radar in band.
• The 40bit to 16 bit conversion is clipped rather than allowed to roll over.

The next 2 images plot the total power vs time for the 5 bands:

• The colors show the different datasets:
• noise shift
• white polA
• red  PolB
• radar shift:
• green polA
• yellow polB
  
• freq bands 2760-2932, 2823-2995, 2964-3136 (.jpeg)
• freq bands: 3107-3278, 3247-3419 (.jpeg)
  
• The negative going spikes align with the max values in the 3136 MHz band

The final image has the rms/mean by freq chan computed every 15.6 ms and the shown as a dynamic spectra (.jpeg)

•  Both frames display polB
• Top frame: pfb noise shift
• Bottom frame: pfb radar shift
• This is missing some of the rfi seen in the top frame
• 3005 MHz
• 3090 MHz
• 3132 MHz
• These freq are probably getting generated when  the noise shift pfb overflows (and wraps around).
  

processing: x101/230627/psr_pshift.pro

---

Summary

• 10 seconds of pulsar data was taken with the pfb pshift set to noise mode and then set to radar mode.
• When the pshift was set to noise mode, there were many pfb overflows.
• these overflows are not clipped, they roll around.
  
• When the pshift was set to radar mode, there were no overflows in the pfb.
• In both modes, there were overflows when moving the spectral data from the 40 bit accumulator to the 16 bit output
  
• This overflow was being clipped.
• When comparing the rms/mean by freq chan every 15.6 milliseconds, the radar shift did not show some some freq spikes shown in the noise shift.
• The extra freq spikes are probably being generated by the pfb  overflows