TMS Meeting Minutes, November 12, 2020

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

Meeting Notes:

Andrew's Analysis:
  • Potentially higher accuracies with shorter angles
  • Stability of approach to channel dropping is under fire
  • Andrew working on his own approach using Etalon channel lengths and dropping different vectors in Jacobian
  • Separating out different aspects of the problem
  • Manual channel dropping with eTalon system
  • Theory points to the fact that this dropping should happen without a big jump, but this is not what we see in the true performance
  • Andrew to use eTalon lengths, then use Jacobians for various dropped channel configs, then look at sensitivity
Heejoo Updates:
  • This past week, many changes to check stability
  • Mostly fine, but two times, enountered TCP/IP communication issues
  • Mark from eTalon set up a loggin system to collect all information to determine the root cause of this failure
  • Strange failure... could query the TCP/IP to get information, comms not severed completely
  • Fault occurred only when asked to take a measurement
  • Solved by restarting the system
  • Interesting problem, as there were no obvious faults to see at the time of failure
  • Now, TCP/IP logging turned on, and we should get more information on this failure
  • Practically, Andrew suggests that we may need a TO who is able to turn on and off the eTalon system/our software
  • Large amount of data collected this past week
  • Heejoo ran a few of Andrew's processes slowly on 2020.11.11
Olga's SuperFoc test:
  • Ea. channel has a different length change when the only applied change is piston
  • When the position of the collimators on the mirror perimeter is taken into account with the appropriate angular displacement...
  • Applying a sinusoidal fitting to data of the applied astig (-5000 nm), and see good fit
  • Heejoo working to apply this method of analysis to Olga's superfoc test
  • Trying to apply same sinusoidal fitting to Olga's superfoc data of length differences
  • Andrew suggests looking at theoretical length change of each channel for a pure delta Z to determine the delta length result
  • Subtract observed changes from theoretical changes to determine the actual result; need to ensure taking a difference to the reference
Windows 10:
  • In principle, we should be able to use Windows 10, but there may be some driver issues and other things required
  • eTalon must be able to modernize their software
  • Andrew has asked about a Linux version
  • Matthieu's only reservation is which distribution is being suggested
  • For consideration, if the Linux version is more barebones with minimized analysis tools in eTalon
  • If we have a strong motivation, we can push it again, but eTalon didn't seem to thrilled
  • John's take, we should use the operating system that the vast majority of their customers use
  • eTalon expanding business quite a lot; were bought by the Hexagon group (of Leica); one of the leading metrology groups in the world
  • The same core team has stayed on, and they've moved to a building 4 times as large

Repeatability Test 2020.11.09 (2 hour):
  • Moving primary to where TMS says it should be
  • 2 ch drop applied as a randomly applied drop to any two channels (ch.11, ch.23-only drop data not yet processed)
  • Full ch. gives much more stable correction than the 2 ch. drop case
  • Z much more stable than XY
  • Andrew suggests some averaging to help smooth this out
  • From prior tests, recall, we saw that the first 30 minutes looked smoother than the latter part
  • John puts forth that this suggests it may not be a coding a problem, but something else
Yang:
  • Our own correction vectors where much different than the eTalon correction vectors as the night wore on
  • Temp only changed about 1-3 K...
  • To analyze this difference, probably need to look at eTalon enviro data, etc.

  • Suggests that it may be worthwhile going back to MATLAB vs. Python Ciddor Correction
  • Yang to look into this, Trenton available to assist as necessary

  • Strong need to continue progressing
  • Need to limit the potential error sources' ability to affect corrections
  • Andrew suggests we decide on a version of the code as a checkpoint solution

  • Heejoo is currently working to prepare a document as a guideline to define the requirements
  • In this doc, should define the required steps for the software to be released

  • For now, need to do a bit of handling to ensure that dropped handles don't send a wild correction in the meantime
Andrew's Analysis, pt. II:
  • When the data is not sensible, there are some change numbers which may still pass by our 1% "bad ch." filter
  • Standard deviation of the lengths is really a good health check for the health of a channel
  • With the current filter, we are allowing a delta of 9.9 ish millimeters
  • We could squeeze this down a bit more to around 6 mm to get better results
  • Failure modes do occur where we are quite close to the acceptable channel values
  • John mentions that the RMS value is still quite small
  • We are worried about the close cousin, the 0.09999% signal, which is rubbish, but still accepted by the filter
  • There are periods of time, on ch. 11, operating at 1% strength, when things have gone amiss
2020.11.09 Dome-Closed, the famous TCP/IP error strikes:
  • 2:00, the famous TCP/IP fault error
  • Right after, 2:0_ something, the pressure of the mirror ventilation system bends the mirror
  • Mirror ventilation from about 2:00 to 5:00
  • What John doesn't understand is that the mirror doesn't seem to act elastically and unbend after the ventilation is turned off
  • If you are guiding, using the WFS, turning on mirror ventilation results in defocus
  • Have to correct this change with active optics
  • Currently, we are missing the on-sky imagery to help check this ventilation focus contribution
  • John confirms that this 7 hour successful run is good enough to request engineering time on-sky at night
  • John wants 2 hours to run the system on-sky
  • Set-point is so the mirror is not ambient (or 3/10th's deg. below ambient)
  • Expect spillover ventilation on steel to result in quick changes

  • We want a list of requirements for getting the software on-sky and then work out the program for technical time
  • Andrew volunteering to get a start on this document
  • One of the main benefits of technical time is getting real images on sky while running TMS
  • Measured starlight to compare to the measured positions
Trenton on Collimators:
  • Will design a lens barrel for the EO achromatic, BBIR fiber collimator (Stock # 65-438)
  • Depending on how well this is designed, could team up with Andrew's company to commercialize this product
Topic revision: r1 - 13 Nov 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