atmos:instruments:wcm:home
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
atmos:instruments:wcm:home [2025/05/23 14:40] – rickbeil | atmos:instruments:wcm:home [2025/06/24 15:43] (current) – rickbeil | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Problems and Solutions ====== | ====== Problems and Solutions ====== | ||
====== WCM ====== | ====== WCM ====== | ||
+ | |||
+ | ===== Problem (Spring 2025) ===== | ||
+ | ==== Introduction ==== | ||
+ | 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, | ||
===== Problem (Spring 2025) ===== | ===== Problem (Spring 2025) ===== | ||
Line 40: | Line 50: | ||
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. | 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. | ||
- | ==== Possible | + | ==== Suggested |
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. | 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. | ||
Line 48: | Line 58: | ||
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. | 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 === | + | ==== 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). | 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) === | + | ==== 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. | 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. | ||
- | These above PID values | + | ==== Solution Two Continued... ==== |
+ | Continuing on with the second solution the PID values | ||
===== Problem (Winter 2024) ===== | ===== Problem (Winter 2024) ===== |
atmos/instruments/wcm/home.1748011227.txt.gz · Last modified: 2025/05/23 14:40 by rickbeil