December 1st, 2020 UT technical night (TMS had second half of night)
Systematic error in OBs images (~20 second exposures)
Andrew guesses it's something we are doing
Christian looked at these images, some crazy exposures with donuts while channel dropping applied
Blue had no convergence
9 channel mode didn't do any harm, only when channel dropping applied
Andrew doing deep dives this month into modelling laser trusses
LBC IQ - 20201201
Very nice, systematic IQ plots
FWHM for blue and red under 4"
Interesting general motion of the IQ
Red and blue both relatively consistent, except for the excursion in LBCr around 11 UTC
This may be around when we started channel dropping
IQ gets really bad when channel dropping applied, and the TMS mis-collimated the telescope
Going to look at Olga's notes for the night
Primary collimation shows a jump, but the jump does not appear to have come from the TMS correction, according to John
Need to get to the bottom of what was going on from 10:20 to 10:50
Here, TMS applying a slowly changing Y correction
Andrew would like to comb through Yang's raw data and to run this through the eTalon software as a gold standard
Suggests we might be able to do a retroactive analysis of the times when TMS/eTalon running passively to compare
Note, at 11:50, both LBCR and LBCB had the same jump, similarly to 10:20
Collimation shows a jump, but only on red
Only 11:50 shows up as a potentially TMS-induced
Trenton to overlay TMS data on the LBC IQ plot from Christian
See Olga's emails for details on which FITS files to look at
Use color coding to delineate when channel dropping was active
Use Yang's TMS data extraction routine to pull out the necessary data for plotting with IQ
At present, we have a system that can run with nine channels, but fails when channels are dropping
John: the jumps are NOT caused by TMS XYZ commands, hasn't looked closely at RxRy yet
A dud channel measurement should give everything a jump, not just X and Y
We see just X and Y collimation corrections
TMS was not sending these
This may have something to do with the interaction with the telescope
There was certainly a period where TMS went crazy with channels dropped and we got donuts
It seems there is something seriously wrong with the dropped channel algorithm, but we haven't discovered this until now
Andrew recalls they made a new reference with 9 channels upon exiting FPIA, then ran TMS with dropped channels
Some discussion as to whether or not we even need a correction vector for dropped channels
Nissen from JPL surprised that we even need a correction vector
Andrew would like to develop a normalized test case for multiple people to check
Andrew to send the data to Yang and Breann to test
In DMS, group rotation is where TMS corrections are recorded (nothing elses uses this)
There is a difference between 9 channel mode and true dropped-channel mode (where artificially induced)
For now, Andrew suggests turning this functionality off until we can figure out what is going on with this
John notes that the jumps appear to be coming from Mode 3 pointing
Mode 1 pointing: when the two mirrors move together
Mode 3 pointing: more complicated motion of the mirrors (associated with co-pointing the binoc)
This doesn't seem to be at the time of the co-point
Heejoo: from engineering night, have confirmed that Olga or others are capable of turning on Yang's code, following the wiki
Heejoo would like to suggest that we don't have to turn off the system all the time to save the life of the laser
Maybe just suspend TCP/IP and then allow the TO to turn it on when needed
Possible problem, eTalon Windows software may not remain stable over long periods of time - Andrew
Yang offers a potential solution: just restart during the day
However, no way currently to leave the laser running when the Windows system restarts
We don't have any leaks through the shutters, which is great
However, there is an email system being developed to send TMS an alert if any laser power is detected
Andrew considers the risk of unintended laser light to be very low, not an irresponsible request
Perhaps, if we need to restart the eTalon system once per week, this could be a workable solution (min/max the system)
Next two weeks are the perfect time to test this, as all of the observations will be in VIS light
Heejoo to turn on the system and get it running
Andrew suggests a telescope work email to inform everyone that the laser is on
The laser-on alarm isn't fully implemented yet, but it is nearly done - Matthieu
On DMS, three voltage levels:
0 - power meter on, shutter closed, no laser leaking
0.8 - power meter on, laser firing
0.001-0.01 - power meter OFF
(if the power meter is left on for five days, it will automatically turn off)
Heejoo added an item to the daily check list to turn on the power meter everyday
Would be great to have an alarm for power meter off when voltage around 0.001-0.01
Andrew will try to have a test case for channel dropping by next meeting
Andrew would like a version of Yang's code which doesn't do any correction when it drops a channel, just send a message
Either sends corrections with 9 channels, or it sends a message that says "not enough channels"
December 1st, 2020 UT technical night (TMS had second half of night) Systematic error in OBs images (~20 second exposures) Andrew guesses it's something we are doing Christian looked at these images, some crazy exposures with donuts while channel dropping applied Blue had no convergence 9 channel mode didn't do any harm, only when channel dropping applied Andrew doing deep dives this month into modelling laser trusses LBC IQ - 20201201 Very nice, systematic IQ plots FWHM for blue and red under 4" Interesting general motion of the IQ Red and blue both relatively consistent, except for the excursion in LBCr around 11 UTC This may be around when we started channel dropping IQ gets really bad when channel dropping applied, and the TMS mis-collimated the telescope Going to look at Olga's notes for the night Primary collimation shows a jump, but the jump does not appear to have come from the TMS correction, according to John Need to get to the bottom of what was going on from 10:20 to 10:50 Here, TMS applying a slowly changing Y correction Andrew would like to comb through Yang's raw data and to run this through the eTalon software as a gold standard Suggests we might be able to do a retroactive analysis of the times when TMS/eTalon running passively to compare Note, at 11:50, both LBCR and LBCB had the same jump, similarly to 10:20 Collimation shows a jump, but only on red Only 11:50 shows up as a potentially TMS-induced
Trenton to overlay TMS data on the LBC IQ plot from Christian See Olga's emails for details on which FITS files to look at Use color coding to delineate when channel dropping was active Use Yang's TMS data extraction routine to pull out the necessary data for plotting with IQ
At present, we have a system that can run with nine channels, but fails when channels are dropping John: the jumps are NOT caused by TMS XYZ commands, hasn't looked closely at RxRy yet
A dud channel measurement should give everything a jump, not just X and Y We see just X and Y collimation corrections TMS was not sending these This may have something to do with the interaction with the telescope There was certainly a period where TMS went crazy with channels dropped and we got donuts
It seems there is something seriously wrong with the dropped channel algorithm, but we haven't discovered this until now Andrew recalls they made a new reference with 9 channels upon exiting FPIA, then ran TMS with dropped channels
Some discussion as to whether or not we even need a correction vector for dropped channels Nissen from JPL surprised that we even need a correction vector Andrew would like to develop a normalized test case for multiple people to check Andrew to send the data to Yang and Breann to test
In DMS, group rotation is where TMS corrections are recorded (nothing elses uses this)
There is a difference between 9 channel mode and true dropped-channel mode (where artificially induced) For now, Andrew suggests turning this functionality off until we can figure out what is going on with this
John notes that the jumps appear to be coming from Mode 3 pointing Mode 1 pointing: when the two mirrors move together Mode 3 pointing: more complicated motion of the mirrors (associated with co-pointing the binoc) This doesn't seem to be at the time of the co-point
Heejoo: from engineering night, have confirmed that Olga or others are capable of turning on Yang's code, following the wiki Heejoo would like to suggest that we don't have to turn off the system all the time to save the life of the laser Maybe just suspend TCP/IP and then allow the TO to turn it on when needed Possible problem, eTalon Windows software may not remain stable over long periods of time - Andrew Yang offers a potential solution: just restart during the day However, no way currently to leave the laser running when the Windows system restarts We don't have any leaks through the shutters, which is great However, there is an email system being developed to send TMS an alert if any laser power is detected Andrew considers the risk of unintended laser light to be very low, not an irresponsible request Perhaps, if we need to restart the eTalon system once per week, this could be a workable solution (min/max the system)
Next two weeks are the perfect time to test this, as all of the observations will be in VIS light Heejoo to turn on the system and get it running Andrew suggests a telescope work email to inform everyone that the laser is on The laser-on alarm isn't fully implemented yet, but it is nearly done - Matthieu
On DMS, three voltage levels: 0 - power meter on, shutter closed, no laser leaking 0.8 - power meter on, laser firing 0.001-0.01 - power meter OFF (if the power meter is left on for five days, it will automatically turn off) Heejoo added an item to the daily check list to turn on the power meter everyday Would be great to have an alarm for power meter off when voltage around 0.001-0.01
Andrew will try to have a test case for channel dropping by next meeting Andrew would like a version of Yang's code which doesn't do any correction when it drops a channel, just send a message Either sends corrections with 9 channels, or it sends a message that says "not enough channels"
Would like to repeat the closed dome tests