Ray fixed the calculation on ACCLEN in incoherent modes. Check this and see if it improves bandpass shapes.
If bandpass still seems incorrect, check IF tuning by configuring for LBW pulsar mode, injecting a tone, and then manually taking data in spectral line Mode 1.
If IF set up is correct, try to set up for L-Band pulsar mode and manually change LBW group number to see if we can successfully recreate the overall bandpass in different segments.
Check calculation and sign of OBSBW and how this impacts frequency labeling in incoherent modes.
Check calculation of OBSBW in coherent modes. Also check that Bank A is active as master but is not writing data.
Check power levels.
Ray and Joe began switching M&C versions a little bit before 09:30.
Submitted i0100x0512 full Stokes with tone injected at 835 MHz scan at 09:56
I think we are seeing the test tone. Bandpass looks qualitatively better than in previous tests. Looks like the tone is there. Levels may not be optimal. Trying again.
vscale at 1000 looks good. Qualitatively the bandpass looks similar to GUPPI. Tone is at the right spot.
Submitted i0200x8192 total intensity with tone injected at 835 MHz scan at 10:07
Bandpass looks qualitatively OK, and tone seems to be in the right place.
Submitted i0200x2048 total intensity with tone injected at 835 MHz scan at 10:09
vscale is set to 1000 but VEGAS is complaining about an illegal value in scale_inco. Seems like that should be valid. Ray and Joe are investigating.
Config file had polmode set as IQUV but it should be only I. Was probably trying to set scale_[quv] when those registers weren't there.
Ray and Joe fixed config file and cycled VEGAS off/on.
Trying again at 10:13. Bandpass seems different than in GUPPI.
Trying again with the tone at 815 MHz. Not obviously seeing tone in VEGAS.
Trying an i0100x4096 total intensity scan at 10:28. Tone is at 815 MHz.
Power levels are too high in GUPPI. VEGAS bandpass seems like all negative values in bandpass plotter. Adjusting levels.
Different vscale parameters don't help. Going to double check that guppi_daq recognizes FAST4K format correctly.
Indeed, FAST4K packet size was not being detected and used correctly. I made this change in a version of guppi_udp.c in /home/dibas but it wasn't pulled into the active branch. Ray is doing so now.
Ray and Joe rebuilt guppi_daq with FAST4K support. Trying again.
vscale of 10000 and 1000 seems too low. Trying 50000.
50000 gives us a tiny signal but we shouldn't have to turn it up that high. Might be an issue with fftshift value, but not sure why the other LBW modes looked OK
Trying a i0200x4096 total intensity mode to check out another FAST4K mode.
If anything the variance is too high. No issue with levels being too low.
Adjusted vscale down, looks better now. But I don't see the cal....
Trying i0200x1024 total intensity
gscale is too high, but VEGAS bandpass seems reasonable.
Looking at the BOF files used for i200x2048, it seems that it was actually an 8k channel BOF. There seems to have been some confusion on my part. That would explain why it looked wrong.
Breaking for lunch. Will do several scans stepping through all available LBW incoherent modes (except i0200x2048 since we know there is an issue with the BOF file for that one). Starting at 12:20. Tone injected for all at 815 MHz.
i0100x0512 bandpass looks OK, cal detected in cal scan
i0100x1024 bandpass loos OK (gscale too high at 2.0). But not seeing the cal signal....
VEGAS i0100x2048 scan never ran. This was a new BOF file, but VEGAS just never went into Running. Ray said that there was an RCP connection problem.
i0100x4096 bandpass levels are too low (like last time). Cal is still just barely visible.
i0200x1024 bandpass looks good, and cal is detected.
i0200x4096 bandpass looks good. Not seeing cal, though.
i0200x8192 bandpass looks good (other than scales being a little high). Not seeing cal again, though.
i0100x2048 scan didn't run again. Same RCP error. Ray is looking at it.
Noticed that switching signal indicator light when VEGAS is switching signal master in LBW modes is not blinking at correct rate. Seems to be more like 0.5 Hz. Confirmed that VEGAS as SS master in HBW modes is correct. This would explain why we weren't seeing the cal in VEGAS only modes (in VEGAS/GUPPI modes DCR is SS master).
Attempted to do some on the fly debugging of the switching issue but it likely requires sitting down with digital and the simulator. Moving on to coherent modes.
Submitted i0200x0128 coherent mode scan at 14:25
OBSBW and OBSNCHAN are still incorrect (a factor of 4 too small). There also seems to be an issue with where the ROACH is broadcasting packets that is causing scans to terminate. Ray and Joe are debugging.
In the meantime, we figured out the issue with the switching signals. The BOF file has a register called n_chan that is used to set the spec tick, which in turn affects switching signal calculations. This was not being set correctly in vegas.conf. Randy inspected the firmware design and provided Joe with a value of n_chan for the i0200x4096 that resulted in the correct spec tick value. Joe added this to vegas.conf and we re-ran an i0200x4096 scan. The switching signal was being controlled properly and the noise diode was visible. This seems to be the last issue (other than the BOF for i0200x2048) that we needed to address for the incoherent modes. Randy will look at designs for other modes and provide the appropriate values of n_chan, which will then be added to vegas.conf. We will then double check that the other modes control switching signals properly when VEGAS is SS master.
Began switching back to main branch at 16:02. More debugging needed for coherent modes.
Checkout scans all look OK. Wrapping up at 16:
Other than needing to verify the SS behavior for all modes, and needing a BOF file for i0200x2048, LBW incoherent modes seem to be working well based on maintenance testing. Neither of these outstanding issues should be difficult to address.
Coherent modes still require debugging, since managers were aborting at the starts of scans and the OBSBW and OBSNCHAN values are still not being set correctly.