Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop a better algorithm for Cropico temperature filtering #279

Open
bberkeyU opened this issue Jun 12, 2024 · 1 comment
Open

Develop a better algorithm for Cropico temperature filtering #279

bberkeyU opened this issue Jun 12, 2024 · 1 comment
Assignees
Labels
enhancement new feature rawdata Issues with raw/L0 data

Comments

@bberkeyU
Copy link
Contributor

A crude filtering algorithm was implemented in the ucomp code to prevent the lyot filter from reacting to noise in the temperature readings, slow the reaction to temperature change, and better match the filter's thermal mass. The theory for slowing down temperature updates is that the heaters and temperature probes are mounted to the outer radius of the filter. However, the temperature we want to know about is closer to the optical axis in the middle of the filter. So if the heat flows into the filter along its cylindrical radius and generally out in its top and bottom, any change we measure at the outer radius will predict the future for the optical elements in the filter.

The filtering algorithm reads a new temperature every 30 seconds, saving both Current_Temp_Read and New_Filter_Temp into the ucomp fits headers
while (True)
{
sleep 30 seconds
New_Filtered_Temp = Old_Filtered_Temp - (Old_Filtered_Temp - Current_Temp_Read)*0.05
Old_Filtered_Temp = New_Filtered_Temp
}

This filtering archives the nominal goal of stopping the filter from reacting to noise in the readouts. It would probably have adequate performances if we didn't see a terminal variation over the day. However, real-world UCOMP thermal data shows a slow Gaussian-like profile with peak temperatures in the filter in the afternoon. The filtered temperatures sent to the lyot filter tuning code roughly follow the actual temperatures. Still, there is a time lag, and the magnitude of this lag changes over time. Worse (but not shown here), the filter resets every time the LabVIEW code is stopped and restarted, so the filtering algorithm also has the hidden input of how long it has been since the last crash (or another stop in observing).

image

Keeping some filtering seems important, if at a minimum, to prevent the tuning from following a noisy read and ignoring high-frequency measurement noise. It is unclear if we should put the time lag into the filtering. And if we should keep the lag, how should we remove the time the observing code has been running from the equation?

@mgalloy mgalloy added enhancement new feature rawdata Issues with raw/L0 data labels Jun 12, 2024
@mgalloy mgalloy added this to the UCoMP level 0 data milestone Jun 12, 2024
@bberkeyU
Copy link
Contributor Author

One possible replacement for the proportional filter we used is an Exponential Moving Average filter.
new_smoothed_value = alpha * new_measurement + (1 - alpha) * old_smoothed_value
Where alpha is a value between 0.1 and 0.3.
If implemented, we would tune the lyot filter with green instead of blue values.
image
image

This should drastically improve things on days when we had funky croprico measurements like 20220902, where, due to a bad initial condition, the applied value was 1-2 degrees lower than the measured value for over half the observing day.
image

We dont know if this properly addresses the thermal inertia of the LN crystals. We still have the problem that the probe is sampling the outside of the crystal near the heater, while the light more or less passes thru the center.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement new feature rawdata Issues with raw/L0 data
Projects
None yet
Development

No branches or pull requests

3 participants