TMS Meeting Minutes, December 3, 2020

Attendees: Andrew, Breann, Christian, Heejoo, John, Trenton, Matthieu, Yang (Zoom Meeting)

Meeting Notes:

  • 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

-- TrentonBrendel - 04 Dec 2020
Topic revision: r1 - 04 Dec 2020, TrentonBrendel
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback