A Tool for Semi-Automated Extraction of Cotton Gin Energy Consumption from Power Data

Abstract

The gin stand power is measurable using common tools; however, such tools typically do not detect active ginning. Detecting active ginning is important when trying to separate out the energy going to the moving parts of the gin stand (i.e., the baseline energy) versus the active energy doing work to remove the cotton fibers from the seed. Studies have shown that the gin stand is the second largest consumer of electricity in the ginning operation, while electricity accounts for nearly 17% of the average expense per bale. If active energy differences exist between cotton cultivars, there may be room to optimize and lower these expenses. The goal of the current work is to provide a method (and software tool) to analyze typical power logger data, and extract periods of active ginning, along with the energy consumed and ginning times, in a semi-automated way. The new method presented allows multiple periods of active ginning in a single file, and can separate the total energy into the active and baseline components. Other metrics of interest that the software calculates include the ginning time, and average power. Software validation using a simulated test signal showed that a 2%-or-lower error is possible with a noisy signal.

1. Introduction

Electricity consumption represents a business expense when ginning cotton. As such, a body of research exists that considers gin stand energy consumption across many different scales of equipment [1,2,3]. On the commercial scale, the gin stand itself has been shown to be the second largest consumer of electricity, behind only material handling [3,4]. A survey of ginners found that the average electricity cost was USD 4.18 per bale, out of a total cost of USD 24.81 per bale [5].

Many variables may affect the energy consumption of a gin stand. Hand-feeding a small gin stand, such as a 10-saw unit with 25.4 cm (10 inch) saws, may introduce some operator effects. Some studies aim to limit operator effects, by limiting data collection to a single operator [2]. Unlike small gin stands, commercial scale equipment uses mechanical feeding to remove variability; one such example is an extractor feeder [6]. Extractor feeders can single-lock the cotton while feeding [7]. Other variables found to affect the energy include the cultivar [1], saw thickness [8], and seed cotton moisture at the feeder apron [9]. Best practices also exist, as a guideline for reducing energy consumption [10].

Energy consumption is a researchable topic in other areas of interest, including cotton production and machine tools. The energy consumption of cotton production has been successfully modeled [11]. Recent work has also compiled significant amounts of the literature related to the energy consumption of machine tools [12]. Other work has focused on the energy efficiency of machine tools that are used for cutting and shaping metals [13]. Additional research has explored the energy efficiency of machine tools in real time [14].

In the cotton ginning industry, there is a growing interest in energy measures, and the isolation of variables effecting those energy measures. A software program to aid in the consistent extraction of energy values from power data would be a valuable tool. Energy studies on gin stands typically involve recording the power, which requires interpretation to extract key metrics: the ginning times, energy consumed, average power, and other information. Furthermore, studies often report the energy as the total energy minus the energy used by the equipment while idling (i.e., they report the net energy) [1,2,15].

Despite the interest in energy measures for cotton ginning, there are no published methods for automatically extracting the energy data and ginning times from multiple runs of cotton included in a single continuous run of the gin stand. The methods outlined in previous works to extract the gin stand energy and ginning times have relied on human actions. One work measured energy, and separated the components, by extracting energy data from a single or discrete ginning session, where the operator powered off the motor at the end of each session [2]. When testing larger-scale equipment designed to run continuously, powering off the motor at the end is not ideal. Furthermore, for some types of gin stands, it can also be hard to judge when to stop the motor, due to the limited view of the seed roll. Other work has determined ginning times by observing the cotton, or by tracking the time for which the gin stand was engaged [1]. Manually timing or observing the cotton can lead to human-induced inconsistencies.

The new “Ginning Energy Extraction” method and software tool presented in this work calculates key ginning metrics with minimal human interaction. Allowing the software to calculate the ginning times removes the variation caused by human judgment. It is anticipated that applying a consistent method to automatically extracting energy from power will allow for better comparisons, by removing the differences caused by process variation. This work aims to provide users with a semi-automated software tool that a user can employ with their high-resolution (and high-sample-rate) power data. The ginning metrics calculated via the software include the ginning time, total energy, and average power. In addition, the software separates the total energy and the active energy (or net energy). The method can handle power data files that contain multiple ginning sessions with one continuous motor run. Furthermore, the software pipeline of the method can track metadata for each run, allowing the user to easily keep track of external variables that they find important, without the need for significant manual labor.

This new method will save significant effort and time, by automating processes. The new method will also make it easier to compare results across studies, by ensuring that data are treated in a consistent manner. The data output from the software tool is saved as a CSV file that can then be used to support the objectives of the user. This may take the form of studying the testing energy or ginning rate versus the cultivar (as others have done, using other means [1,2,15]), checking the baseline energy of the equipment, and much more.

2. Materials and Methods

2.1. Example Data and Software Pipeline

Figure 1 provides an example of high-resolution power data taken from a 10-saw gin stand with 25.4 cm (10 inch) saws. The vertical axis is the power recorded, and the horizontal axis is the time in 0.2 s increments. An AEMC model PEL 105 power logger (AEMC Instruments, Dover, NH, USA) captured the power data. The logger takes 128 samples per 60 Hz AC cycle, and saves an aggregate value to the user-accessible memory every 200 milliseconds [16]. In this way, aliasing is not a concern, and the data sample rate is high enough to work well for the example application. The gin stand took power from a 3-phase 240 V 60 Hz source. The power logger had both a current sensor and a voltage probe on each phase, which allowed it to calculate the wattage. The total run time shown in Figure 1 is nearly seven minutes, and there are nine separate temporal slices of higher power (approximately 700 watts) that represent periods of active ginning within the single file. Periods of time where the equipment was idling separate the periods of active ginning; these are the lower power states observed between the peaks. In this example, the majority of the datapoints represent idling equipment that is consuming some baseline level of energy. In addition, the baseline power level shifts with time. The baseline power level tends to decrease as the equipment warms up; this trend may not happen in all cases, but the software should be able to account for this, especially as the run time increases. This example dataset will serve to illustrate and validate the workings of the “Ginning Energy Extraction” method in future sections.

Figure 2 provides a high-level view of the software pipeline for the “Ginning Energy Extraction” method. The main steps are in boxes A–F, including: (A) import data, (B) power data filtering, (C) main loop control, (D) model baseline power, (E) detect ginning and get energy, and (F) build output. The overall goal of this pipeline is to detect periods of active ginning, and then calculate the total energy, along with the active energy, ginning times, and average power values. The high-level design is such that block A allows a user to import multiple CSV files, each containing high-resolution power data recordings. Power data from a cotton gin stand are typically noisy; therefore, the next step (block B) filters all the power data, to reduce the noise that is present. After that, a main loop begins with block C. The main loop allows the software to independently process the data contained in each CSV file loaded previously. Within the main loop, two major things happen. Firstly, block D models the baseline power consumed by the equipment. That is, it models the power consumed by the equipment while it is running but not actively ginning cotton. The software uses this result to determine when ginning is happening, and to separate the energy into active and baseline components. Secondly, block E detects periods of active ginning, and integrates these to obtain the active energy, total energy, baseline energy, ginning times, and average power levels. Finally, after the code has processed all the data, block E builds the outputs. In this way, the software can process all the datasets, and provide a single output file containing all the results.

The rest of Section 2 of this work will illustrate each of these steps, while working through an example. The title of each subsection is the same as the name shown in the flowchart. After this, Section 3 provides the results of the example, and details of the software validation performed. Several stages of the pipeline have user-tunable hyperparameters. These parameters are constant values that fine-tune how the algorithm works. A user may achieve a better result for their dataset by adjusting these values. Some examples that may warrant adjustment include user data that are noisier than the examples provided, or a power rise much larger or smaller than in the example data. The hyperparameters are pointed out, where appropriate, along with their default values used for the example data. Appendix A provides a list of the hyperparameters, along with default values for, and descriptions of, each. Appendix B.1 through B.3 provide the source code that will be discussed. All code written for this method is in the Python language [17] version 3.7.6, and it relies on pandas [18] version 1.2.0, numpy [19] version 1.19.2, and SciPy [20] version 1.5.2, as well as several others, as shown in the code.

2.2. Import Data

The main purpose of the import data stage is to move the data into the software in a format that is usable for completing the calculations. This stage operates as shown in the chart in Figure 3. At this point, the user provides the path to the folder containing the power data CSV files, and the name of the column containing the power data within the CSV file (this name will be ‘PT (W) (200 ms)’ in the example data provided). This folder can contain multiple files. Next, the user provides a “user input” file that contains three columns with one entry (row) for each power data CSV file that the user provided. The first column of the “user input” identifies the name of the CSV power file that the “user input” applies to. The second and third columns are the start and stop index for a user-identified continuous region, representing “typical idling”. Block A01 uses a pandas [18] DataFrame to hold these data, and

Table 1. Example of a required user-inputted file.

File	UserStart	UserEnd
data001	8200	8800

provides an example for a single CSV file. A discussion of how the code uses the user input comes later. Finally, the user can optionally provide a file containing any metadata, which the code reads into a DataFrame in block A02. A discussion of the metadata, and their format, comes later. Once the user has provided all the paths and files, block A03 checks the input folder, and acquires a list of all the files in the folder, after which block A04 imports any CSV files into a DataFrame. Appendix C provides the typical file structure used by the code.

The optional metadata that a user may elect to include can be very helpful if there are some important external variables, beyond the metrics that come from the power data. These types of variables may be important in subsequent analysis, such as statistical modeling. The metadata may include a wide variety of items, such as weather data, blocking factors, machine information, or any other variables that a user wants to track with each run of cotton. The metadata link to the power data through the filename. If a user provides metadata, they must contain a column for the filename, and the entries must match the names of the CSV files that contain the power data. There must also be 1 row in the metadata file for every period of active ginning in the power data file, and they must have the same order (i.e., for each file name, row 1 in the metadata must be power run 1, row 2 must be power run 2, and so on). The total number of points does not matter.

Table 2. Optional metadata minimal example.

File	Run
data001	1
data001	2
---	…
data001	9

provides a minimal example; the first column is the file name the data refer to, and the second column is the run numbering (which must be in the same order as it is in the power file). A user can add any additional columns, as desired.

2.3. Power Data Filtering

The goal at this stage in the pipeline is to reduce the noise found in the raw power data, to aid in the calculations performed later. Figure 4 shows the steps involved in this process.

The input to this stage is the raw power data in the form of a list, where each list entry is a DataFrame that contains the data from the CSV file that the user inputted. The length of the input list is the number of CSV files that the user inputs. The first step in this stage of the pipeline is block B01, where the software constructs the filter coefficients. A finite impulse response (FIR) filter [21] is generated using SciPy [20], specifically through the “firwin” method, with the “Kaiser” window. The beta value is 4.53, and the filter is set up to be a low-pass filter, with 31 taps, and a cutoff frequency of 0.5 Hz. The “kaiserord” method in SciPy calculated the beta value and the number of taps, such that the transition window is 0.5 Hz, and the ripple is 50 dB (ensuring a less-than-1% ripple variation in the pass band). The transition window and ripple are hyperparameters that the user can adjust, depending on their data. The cutoff frequency (0.5 Hz) was well below the data aggregation period of the example data (5 Hz), and was chosen as there was not a lot of useful information beyond 0.5 Hz. For the example data, each period of active ginning had at least 150 samples; this is significantly more than the length of the filter, with 31 taps. Figure 5 provides the frequency response of the filter.

After crafting the filter coefficients, the software goes into a loop in block B02. The purpose of this is to iterate through all the entries of the raw power data list one at a time. Each pass of the loop operates on the contents of a single CSV file, which the system loaded earlier (each file may contain multiple runs). Within the loop, block B03 uses the SciPy [20] “lfilter” method to apply the digital filter to the data column identified by the user as power data. Next, block B04 left-shifts the result, to compensate for the lag introduced by the filtering process, using knowledge of the number of taps in the filter. The lag correction is an optional step, but it does make it easier to plot any comparisons with the unfiltered data. The last step in the loop is block B05, where the software appends the data to a list of filtered power arrays. By the last run of the loop, the list of filtered power arrays has as many entries as there were CSV files in the user-supplied folder. All remaining calculations rely on the filtered data. Figure 6a shows the raw data before filtering, while Figure 6b provides the result after filtering.

2.4. Main Loop Control

The goal of the main loop stage is to allow the code the flexibility of working on multiple datasets loaded at a single time. The reason for the loop is that the main processing stage (i.e., blocks D and E from Figure 2) are only designed to operate on a single dataset that may contain multiple runs. The main loop allows the code to process multiple datasets, by iterating through all the datasets, and presenting them one-by-one to the main processing stage, independently. The code appends the output of each loop to a list that holds the values until all the datasets finish processing. After this, the list passes on to the build output stage in block F from Figure 2. In this way, the results from all the datasets populate a single output file.

2.5. Model Baseline Power

The goal at this stage is to model the baseline power of an individual dataset. At this point, the control loop from block C has passed in the filtered power data that represent a single CSV file imported by the user. In addition to the specific filtered power data, this stage has access to the metadata DataFrame discussed during the import stage, and the user input DataFrame previously discussed. Figure 7 provides the steps involved at this stage.

The first step of this stage is block D01. This step starts by retrieving the filename of the data that the main loop passed in. The code then uses the filename to look up the relevant metadata (if the user provided them), along with the UserStart and UserEnd values from the user-inputted file. Table 1 provided an example of the UserStart and UserEnd values. The metadata are not part of any calculations. The software only tracks them to ensure the ordering, and then inserts them into the final output compiled in block F, from Figure 2. We have mentioned that the UserStart and UserEnd terms define a range that the user considers to be “typical idling.” How the software uses the “typical idling” range will be explained later.

Next, block D02 calculates the approximate magnitude of the second derivative of the filtered power data, to get a sense of how quickly the slopes of the power data are changing (i.e., how jumpy the data are). The assumption made is that a gin stand will show less variation in the power signal when idling than while actively ginning. The approximate second derivative is calculated using numpy [19], through taking the absolute value of the second discrete difference using the “numpy.diff” method. After this, block D02 calculates the estimated maximum value of the second derivative expected for idling. This calculation is based on the user-supplied “typical idling” range. The code calculates the estimate using the pseudocode of Equation (1):

$$\mathsf{\beta }=\mu \left[UserStart:UserEnd\right]+STDEV\ast SD[UserStart:UserEnd]$$

(1)

where $\mu$ is the mean of the approximated second derivative from index UserStart to UserEnd, SD is the standard deviation over the same range, and STDEV is a hyperparameter with a default value of 3. For the example data, UserStart is 8200, while UserEnd is 8800, as shown in Table 1.

Now that the system has the estimated maximum value of the approximated second derivative (i.e., $\mathsf{\beta }$), block D03 compares β against the whole approximated second derivative array. In this way, the code identifies the indices where the value of the array is less than β (i.e., points beyond the user “typical idling” range that may also represent idling equipment). In other words, applying the above-stated assumption that an idling gin stand will show less variation in the power, this block is looking for the low-variation points. The output is a binary array where a value of one means that the code has estimated that the filtered power data at the same index location represents idling. The result obtained can be noisy, with rapid state changes. A hysteresis function applied to the binary array reduces this unwanted noise.

Block D04 applies the hysteresis function, which has three tunable hyperparameters: Window (W), Set (S), and Reset (R). The W term controls the size of the rolling window in counts; each count is 0.2 s for the example data. The size of each count may change for a user’s dataset, depending on the sample rate of the source data. The output of the hysteresis only goes high when the sum of the window data is at least equal to S counts. Once the output is high, the input must go low for enough counts to cause the sum of the window to be less than R, for the hysteresis output to go low. In any case, the R term must be equal to, or smaller than, the S term. In addition to smoothing, this introduces a lag that can remove startup effects by rejecting the first portion of the signal. The software code provides more details on the hysteresis function. Figure 8 shows the hysteresis function working on example data, using W = 50, S = 50, and R = 45. In Figure 8a, the raw data include some rapid state transitions before and after a more stable period, while Figure 8b provides the sum of the window data, and Figure 8c shows the final output.

Once the estimated idling points are all found, block D05 fits a linear curve to these points. Figure 9 shows the user selection (i.e., the user-selected “typical idling” region) as the horizontal dotted line, the filtered power data as a solid red line, the datapoints included in the fit (blue dots), and the curve fit (yellow line), which models the baseline power. In cases where users determine that curves other than a linear fit are a better choice for their data, the code can be modified accordingly. In this example, the modeled baseline power decreases with time. This decrease matches the trend discussed when describing the raw data in Figure 1. In essence, as the gin stand warms up, the baseline power decreases. Potentially many factors contribute to the decrease (the properties of the lubrication, the dimensional stability of mechanical parts, friction, heat in the electronics and motors, etc.). Ideally, all equipment would have time to warm up before use. However, baseline modeling allows the software to handle the warmup effects if a warmup period is not feasible. The final output of this stage is an array-like object that contains the modeled baseline power curve.

2.6. Detect Ginning and Obtain Energy

The goal of this stage in the pipeline is to detect periods where ginning is actively happening, and then extract useful energy and power metrics from it. This stage generates the results that the user ultimately reads. At this point, the code has access to the modeled baseline power array (the output from Figure 2, block D) as well as the filtered power array provided by the main control loop from block C, in Figure 2. Figure 10 provides the steps involved at this stage of the processing.

The first step in this stage is to find periods where ginning is actively happening, as shown in block E01 of Figure 10. The code does this by comparing the filtered power data (from Figure 2, block C) with the modeled baseline power (from Figure 2, block D), to find points in the power that have a magnitude lower than some percentage over the baseline. The pseudocode of Equation (2) serves this purpose:

$$test=\left[p_d<(rise\ast b)\right]$$

(2)

where $p_d$ is the filtered power data array that represents all the power data from a single CSV file the user inputs, $b$ is the modeled baseline power array that corresponds to the power data array, rise is a constant, and the output test is a binary array or True/False values. The default value of rise is 1.1, a hyperparameter. In the special case where there is some null value in the array, the code treats that point as if idling, for calculation purposes. The active ginning intervals are then simply the inverse of test. The inverse comes from flipping all the elements of test, such that every 0 (or False) turns to a 1 (or True), and every 1 (or True) becomes a 0 (or False).

The result from block E01 is noisy. As before, a hysteresis function reduces the noise, as shown in block E02. The hysteresis function is the same as was described in Figure 7 block, D04, except that the parameters (W, S, R) have different values. The exact values are hyperparameters that may require tuning for application. The result of this step provides the periods of active ginning. Figure 11 shows the filtered power data, along with the baseline power curve fit, and the active ginning periods just discussed.

Once active ginning periods have been established, these active regions are separated out in block E03. At this point, the code generates the ginning times for each active period, based on the sample rate and the number of points contained in the active regions. The software then integrates the individual active regions, to obtain the energy. In this case, SciPy [20] provides the “trapz” integration method. The software integrates both the total power and the baseline power for each period of active ginning. This results in the total energy and the baseline energy for each period of active ginning.

Using the total energy and the baseline energy, the software calculates the active ginning energy (i.e., the portion of the energy doing work on the cotton, plus any additional losses). To illustrate, Figure 12 shows the process using only the first run of the example data from Figure 1. The software subtracts the calculated baseline energy, as shown in Figure 12b, from the calculated total energy, as shown in Figure 12a, to acquire the active energy, as shown in Figure 12c. When the data include multiple runs, the software simply subtracts the first baseline energy value from the first total energy value, the second baseline energy value from the second total energy value, and so on.

Block E03 also provides the average power levels for each period of active ginning. To obtain the average total power for each period of active ginning, the code divides the total energy of each active ginning period by its associated ginning time. To get the average baseline power for each period of active ginning, the code divides the baseline energy for each active ginning period by its associated ginning time. The total energy, active energy, average baseline power, average ginning power, and ginning times are all saved to lists, for use in the next step of the pipeline.

2.7. Build Output

The goal of this stage is to build the output, and save it into a format that is useful to the user. This step begins after the main control loop from Figure 2, block C determines that there are no more filtered power data to process. Figure 13 provides the steps involved.

Block F01 transfers the calculated values from the lists that stored them into a DataFrame. Next, the software appends the metadata (if provided) to the DataFrame. Finally, the code saves the DataFrame to a CSV file. It should be noted that combining the metadata with the calculated metrics works only if the number of rows in the calculated values matches the number of rows in the metadata.

3. Results and Discussion

Up to this point, an example dataset that was introduced in Figure 1 has served to illustrate the steps involved in the new method presented. Now that all the processing is complete, and the software has created the output CSV file, the results can be inspected through opening the CSV file.

Table 3. Example output results, as saved to the final CSV file.

B_Energy_Whr.	T_Energy_Whr.	Act_Energy	Time	Base_Avg._W	T_Avg._W	File	Run	Temp [f]
6.14	8.13	2.00	50.6	436.57	578.52	data001	55	66.7
4.83	6.23	1.40	40.0	434.43	560.32	data001	56	66.6
3.72	4.68	0.96	31.0	432.47	543.58	data001	57	66.7
4.76	6.17	1.41	39.8	430.49	558.16	data001	58	66.8

provides the first five rows of the CSV file (i.e., the header plus the first four runs in the data). The first six columns of the output are the calculated parameters (i.e., the base energy, total energy, and active energy in watt-hours, followed by the ginning time in seconds and, finally, the base average power, and the total average power in watts). The remaining columns of the output data are the optional metadata that were included. In this case, the metadata shown comprise the minimum example in Table 2, along with the ambient temperature information for each run.

The results found in the CSV file can now be used for scientific purposes, depending on the needs of the user. A common scientific purpose to which this method could be applied is in testing for correlations between cultivar and energy or ginning time, as seen in other studies using older methods [1,2,15]. Applying the new method presented in the current study would require simply providing the cultivars being tested and the sample sizes as metadata, along with the power files recorded at a high-enough sample rate. The newly presented method would eliminate the need for the operator to power off the motor, or for anyone to time the ginning periods. Allowing the software code to detect the start and stop times for periods of active ginning reduces the variation introduced by humans having to take action.

Software Validation

The previous sections focused on example data taken from a real-world test, to illustrate the method and the software pipeline. This section now focuses on a known simulated test signal, to validate the software. The validation works by feeding a test signal (of a known power, energy, and period) to the software, while comparing the calculated outputs to the known values. Figure 14a shows the clean test signal: a square wave with a baseline power of 300 watts, and a peak power of 700 watts. The overall length of the signal was 900 points, with a point generated every 0.2 s, and a high signal for 300 points. Figure 14b shows the signal after the addition of noise to the test signal. The test signal includes the random noise having a mean value of zero, with a larger standard deviation in the 700-watt region of the signal.

Figure 15 provides the results of running the noisey signal through the pipeline as described. The plots include the detected ginning period, the ideal power fit, and the user input (i.e., the data available after Figure 10, block E02). Figure 15a is the result when the hysteresis window in Figure 10, block E02 is set to 50 counts, and Figure 15b is the result when the window is set to 10 counts. Reducing the window size reduces the lag between the end of the test signal pulse and the end of the detected active ginning time. Unlike the sharp drop in the test signal, some lag may be beneficial when measuring real ginning data, because the power level slowly drops, as the cotton works through the gin stand. The window is a hyperparameter, which allows the user to fine-tune as necessary to the specific data in use.

Table 4. The test signal validation test results.

	B_Energy_Whr.	T_Energy_Whr.	Act_Energy	Time	Base_Avg._W	T_Avg._W
Real	5.00	11.67	6.67	60.0	300.00	700.00
Window 50	5.72	12.23	6.51	68.8	299.08	639.98
Window 10	5.05	11.56	6.51	60.8	299.01	684.22
% Error 50 *	−14%	−5%	2%	−15%	0%	9%
% Error 10 *	−1%	1%	2%	−1%	0%	2%

* %Error 50 and %Error 10 calculated as $(Real-Calc)/Real$.

shows the calculated outputs from the code pipeline, along with the theoretical values that come from the known test signal (i.e., the row titled ‘Real’). Looking at the window 50 and window 10 rows versus the “Real” row, we can see that the code is working, with the error decreasing for the square wave test input as the lag reduces. This result illustrates the effect of the window on the results, and the flexibility of the pipeline that allows user adjustments based on the type of data. The validation study confirms that the software functions as designed, and can produce accurate results that can fit the data, while factoring in user inputs.

4. Conclusions

Common tools can measure the gin stand power; however, such tools typically do not detect active ginning. Active ginning detection is important when separating the total energy calculated into the energy going to the moving parts of the machine, versus the active energy doing work on the cotton (plus any losses). Separating out the energy allows energy optimization work to target the machine design, or target the cotton cultivars. An automated tool to detect active ginning, and calculate common metrics, would be of value to the community, as it could ensure the consistent treatment of data across studies.

The goal of this work was to provide a semi-automated tool to analyze typical power data recorded using common tools that can detect ginning, and separate out the components of the energy. To that end, a software program was created to analyze power data utilizing open-source packages. The software takes in the raw power data, filters them, models the baseline energy consumption of the equipment under test, detects active ginning, and calculates the ginning metrics: the ginning times, energy consumed, and average power. The new method works on files containing multiple runs of cotton in a single file. The output from the software can be used to support the objectives of the user. This may take the form of testing energy or ginning rate versus cultivar, checking the baseline energy of the equipment, etc.

Software validation tests found that, using a simulated noisy signal, it is possible to control the error in the calculated energy, ginning time, and average power to 2% or less, versus the theoretical values for the signal with no noise. The new semi-automated method presented herein will save time, while also making it easier to compare results across studies, by ensuring the consistent treatment of data. It is anticipated that, by allowing the software to automatically extract ginning intervals, and calculate important metrics, human-induced variation can be reduced. This may also make it easier to compare results obtained by different groups, through applying common calculations across studies.