Check for any possible frequency shift in or other issues in i0100x0512 (there was some extra pulsar smearing in on-sky data)
Check for any possible frequency shift in Mode i0200x1024 using search mode (there appeared to be a 20 MHz offset in on-sky data)
Check for any parameter errors in Mode i0100x2048
Possibly check GUPPI OBSNCHAN parameter in dual backend configuration for Modes i0800x0064 and i0800x0128
Session begins at 10:05
Ray and Joe already switched M&C versions
Ryan updated vegas.conf with new BOF file names and modes.
Did all prep work and turned VEGAS off/on
Scheduling block VPM/GUPPI-LBW-Test submitted at 10:23. Will take i0100x0512, i0100x1024, i0100x4096, i0200x1024, and i0200x2048 scans in all obs modes.
i0100x0512 scan only ran with VEGAS, but the cal signal is seen. S/N is not great. I think I had some old edits to the scheduling block that stopped GUPPI from running. Changing those and resubmitting so I can compare with GUPPI.
Resubmitted SB at 10:28
GUPPI is now configured fir i0100x0512 scan
Cal seen with good bandpass levels in both GUPPI and VEGAS. Scan lengths and metadata seem good. Tone seen in both backends at right frequency. Bandpass shapes are not complete identical but overall features are similar.
Levels are a little low on VEGAS in i0100x1024, but tone is seen and bandpass features seem similar to GUPPI. Cal is seen in both backends. Scan lengths and metadata seem good.
GUPPI activated properly in i0100x4096 mode but VEGAS took a long time to activate, and then eventually threw a fault and aborted saying "Aborting: not enough time to start scan". I am continuing on but we will need to come back and look at this.
VEGAS had an invalid start time for the i0200x1024 scan and aborted again. Might be in a bad state from the last scan. Cycling off/on and picking back up with i0100x4096 scan again.
Resubmitted at 10:57. VEGAS is still taking a long time to activate. Aborting and skipping to i0200x1024.
Resubmitted at 11:02. VEGAS has wrong nchan and BOF file. Maybe editing vegas.conf with the i0100x8192 mode messed something up. Getting rid of that entry to see if it helps. No effect. Giving Ray a call.
Ray helped restart subsystems that relied on DDLs generated from config tool, and Joe modified config tool to recognized the i0100x8192 mode. Starting again at 12:10 with i0100x4096.
VEGAS still taking a long time to activate for i0100x4096. Joe and Ray suggested not turning VEGAS off/on after it fails, and trying to run the mode again. This had no effect. They are trying to determine why it is taking so long to activate.
Will continue with i0100x8192 while they diagnose. SB submitted at 12:32
Levels are too high on i0100x8192. Trying again with vscale set to 1000. Levels are still too high. Levels looked somewhat better with vscale set to 300. Bandpass is not quite right, so I think there is still some frequency shift htere, but the IF set up looks good and the cal is seen. There is a lot of packet loss with 81.92 us tint. But I'm going to move on from this for now.
titania lost power and rebooted around 13:10. Recovering.
Joe and Ray say that the packet size in the i0100x4096 mode is 8224 bytes, which is the size for a 1SFA packet, but these should be FAST4K packets.
Trying i0200x1024 mode.
Bandpass agrees with GUPPI in the vpmMonitor and guppi_monitor windows. Tone is at right frequency. However, the psrfits files seem to have a shift in the bandpass in VEGAS. OBSFREQ, OBSBW, CHAN_BW, and OBSNCHAN are all correct in shared memory. Cal-mode data seems to agree with this in psrfits for full stokes mode (cal and search). However, with only I there seems to be a frequency shift in the folded data.
Actually, the shift doesn't seem to always happen. Which is really frustrating.
Now I can't reproduce this... Moving on.
No packet flow in i0200x2048.
I changed the packet format for i0100x4096 to be 1SFA.
Scans are running now.
Levels are too high, but the tone is seen at the right frequency and the cal is also seen.
Changed vscale to 500 and levels are now a little low, but bandpass looks OK.
Moving on to i0800x2048 and i1500x2048 modes.
i0800x2048 bandpass looks good. Cal is seen in only one cycle. Data length and metadata are all correct. Tone is at correct frequency.
i1500x2048 also looks good.
Going to check i0100x2048 mode. No new BOF file but might be able to diagnose.
Packet size indicates 1SFA format here, even though vegas.conf says it should be FAST4K. Going to try with 1SFA in vegas.conf
Scans are running with 1SFA packet format. vegas.scale is way too high, so will decrease to 500 and see how things look.
Bandpass looks very good with different vegas.scale. Tone shows up at right frequency. Cal is there. Metadata and scan length all correct.
No packet loss in i0100x8192 with tint = 163.84 us. That's cool!
Checked ARP table and IP config in i0200x2048 and all seemed OK, but still no packets. On a whim, tried changing packet format from 1SFA to FAST4K but no effect.
Ray is switching back to release branch at 15:39
Checked GUPPI/VEGAS, VEGAS (pulsar and Mode 1), and GUPPI. All seem OK.
Session ended at 16:10
i0800x2048: Checks out!
i1500x2048: Checks out!
i0100x0512: Checks out!
i0100x1024: Checks out!
i0100x2048: Checks out with 1SFA packet format, even though the vegas.conf, BOF file, name and expectations indicated that it should be FAST4K. Need to confer with Randy about this.
i0100x4096: Checks out with 1SFA packet format, even though vegas.conf and expectations indicated that it should be FAST4K. Need to confer with Randy about this.
i0100x8192: Scans ran OK but the same frequency shift that appeared in the simulator seems to be happening here, too. Packet loss in search mode with tint < 163.84 us and full stokes.
i0200x1024: Could not consistently reproduce the 20 MHz shift that was seen in astrophysical commissioning and in some scans today. Not sure how best to proceed with this.