Differences

This shows you the differences between two versions of the page.

--- atmos:instruments:wcm:home [2025/05/07 19:10] – external edit 127.0.0.1
+++ atmos:instruments:wcm:home [2025/06/24 15:43] (current) – rickbeil
@@ Line 4: / Line 4: @@
 ===== Problem (Spring 2025) =====
 ==== Introduction ====
-When water droplets go from being present to not being present over the probe head there is a noticeable decay in the data which causes a exponential decay of sorts to be present. This then results in an indication that water droplets are supposed to be present even though there are no droplets passing over the probe head during this decay period of time. Attached below are photos and graphs that better visualize the problem that is present while using the WCM probe.
+During previous field campaigns in which the WCM 3000 was used it had been noticed that the initial value during no water content present was a non zero value. This is still noticed in the WCM 3000 where on initial start up the probe indicated that there is water content present. This issue was normally resolved with post processing of the data from past campaigns where the non zero data would be adjusted down to zero and then further studied after that correction was applied.
+==== Cause ====
+In the fml.300 table that is present on the m300 computer and is used by the WCM data collection software it was noticed that the code that is supposed to correct for this non zero value wasn't included in the table. There was however correction code in there but it appeared to be from the older WCM model in which it had a compensation term that would remove this non zero value and instead keep the probe at a zero value until water content is present.
+==== Solution ====
+In the manual for the WCM 3000 probe there is a section in which a couple different ways are discussed as to how to get the probe to go to a zero value during the non presence of water. The way that was used in our correction of this issue was as follows; Psensedry = K1 * (Tsense - Tambient)*(Pambient * TAS)^k2. Where Psensedry is the value that is subtracted from Psensetotal which gives us Psensewet, K1 is a constant that is used which can be changed based upon testing of the probe, Tsense is the temperature of the sensor, Tambient is the ambient temperature, Pambient is the ambient pressure, TAS is the true airspeed, and K2 is another constant that can again be found by testing of the probe. This together does appear to work in the laboratory setting but still should be tested in the field as the higher airspeed values might cause the need for changing the constants K1 and K2 as needed.
+===== Problem (Spring 2025) =====
+==== Introduction ====
+During the use of the WCM it was noticed that when compared to other instruments such as the Cloud Droplet Probe, RICE probe, and the hot wire boom probe there is a decay present after the water content should have gone to zero over the probe head. This is now something that is being lab tested to better understand what is going on with the probe and to try and correct this invalid data that is being collected. Below are references to where the data is located for this particular lab run.
   * Reference: /nas/und/NorthEast/2025/Lab/CH423/GroundData/20250416_165626/PostProcessing
@@ Line 30: / Line 40: @@
 ==== Decay Graphs ====
-{{:atmos:instruments:wcm:wcm_graph_17_02_00_m-300.png?400|}}
+{{:atmos:instruments:wcm:wcm_graph_17_02_00_m-300.png?400|}} {{:atmos:instruments:wcm:wcm_graph_17_04_00_m-300.png?400|}}
+{{:atmos:instruments:wcm:wcm_graph_17_06_00_m-300.png?400|}} {{:atmos:instruments:wcm:wcm_graph_17_08_00_m-300.png?400|}}
 Top left - 17_02_00 Graph, Top right - 17_04_00 Graph, Bottom left - 17_06_00 Graph, Bottom right - 17_08_00 Graph
@@ Line 36: / Line 48: @@
 Each graph is marked at roughly where the video indicated no more water being present over the probe head.
-The way that I determined the delay interval was by determining that each tick on the graph is roughly one second of data and then counting the ticks it took to get to a baseline value. The way I determined this baseline was by observing where the data mostly stabilized at so this is mostly subjective in terms of determining this value. But I mostly settled on a value of at or below 2.2 on the x-axis. The corresponding values that I then found for each graph are as follows; 6 seconds for 17_02_00, 6 seconds for 17_04_00, 4 seconds for 17_06_00, and 7 seconds for 17_08_00. This then came out to be an average of 5.75 seconds of data present during this decay. Then after applying the 66.7% validity to this average I found that there is about 3.84 seconds of incorrect data during these runs.
+The way that I determined the delay interval was by determining that each tick on the graph is roughly one second of data and then counting the ticks it took to get to a baseline value. The way I determined this baseline was by observing where the data mostly stabilized at so this is mostly subjective in terms of determining this value. But I mostly settled on a value of at or below 2.2 on the x-axis. The corresponding values that I then found for each graph are as follows; 6 seconds for 17_02_00, 6 seconds for 17_04_00, 5 seconds for 17_06_00, and 7 seconds for 17_08_00. This then came out to be an average of 6 seconds of data present during this decay. Then after applying the 66.7% validity to this average I found that there is about 4.00 seconds of incorrect data during these runs.
+==== Suggested Solutions ====
+After contacting SEA they suggested that a possible reason for this issue is the PID controller that is in the WCM may not be set to correct settings thus resulting in a decay in the graph after water content becomes non present. It was also shared that there are a couple different settings that they tested when calibrating the WCM 3000 where they gave us what the default values should be along with a mid aggressive and aggressive setting for the PID board.
+=== Implementation ===
+These values were all tried and each one preformed in a manner that wasn't necessarily similar to what SEA had gotten for results after using these values. The output was more so aggressive when set to an aggressive setting as it should be but there were still noticeable decays in the graph even with these more aggressive values.
+From here values were changed based upon the way that PID controllers should be calibrated where you first start with the Proportional term and get it to an appropriate value that causes the instrument to operate stable and then you adjust the Integral and Derivative terms as needed to get the output from the instrument to be as stable and responsive as possible. After changing these values many times there was still the same decay issue present in the recorded graphs.
+==== Solution One to Decay ====
+Checking the fml.300 table within the m300 computer it was noticed that the data this is being recorded is being averaged which seemed like it could be causing an issue with our recorded data and thus was removed to see the effect. After removing this averaging function there was a noticeable improvement in the data collected where now instead of these long 5 to 7 second data delays there was now only about a 2 to 3 second delay present with the data (This delay can now be fixed by tuning the PID controller).
+==== Solution Two to Decay (Tentative) ====
+Now that the long decay was removed from the graphs by removing the averaging function in the fml.300 table the PID controller should now have a more noticeable impact on the data collected. **Another thing to note which was found during the initial PID tuning was that the derivative term will also contribute to a decay since the derivative term is acting as a dampener to stop the probe from immediately going to zero after water content is stopped.** So now taking that into account when tuning the PID board it is known that the derivative term should be set fairly low so as to stop the probe from over dampening itself during data collection. The values that were found that allowed the probe to work fairly well are as follows; **(TWC terms Kp- 2000 Ki- 90 Kd- 20) (LWC terms Kp- 9500 Ki- 95 Kd- 20)**. These values were only tested during no airflow to try and calibrate the probe to be as stead as possible. This was done as a control just to factor out the unpredictability of the airflow that would normally be present over the probe and to make the tuning of the probe more easier.
+==== Solution Two Continued... ====
+Continuing on with the second solution the PID values were now tuned with airflow present over the probe which did result in different values from the zero airflow calibration. The values that were found are as follows **(TWC terms Kp - 1500 Ki - 25 Kd - 200) (LWC terms Kp - 2000 Ki - 25 Kd - 150)**. These values overall did improve the response time in the WCM 3000 but something to still note is that these are not perfect. There is still a 1-2 second delay present in the data which seems to be just a limitation of the probe itself and not necessarily something that can be fixed. **(These values have yet to be tested on an aircraft at higher airspeeds meaning that these are still subject to change since these values were only derived at lower airspeeds, further updates may be needed to these values)**
 ===== Problem (Winter 2024) =====