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
Depending on how well this is designed, could team up with Andrew's
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 Depending on how well this is designed, could team up with Andrew's