These are a few suggestions for maximizing the accuracy and consistency of RS92 radiosonde RH measurements. Also see Appendix A of Miloshevich et al. .
Output the FLEDT data files rather than the older EDT file format if possible (requires having a Digicora III data system). FLEDT ("floating-point EDT") files are identical to EDT files in every way except that the RH data are not unnecessarily rounded to integer values but contain some decimal places of precision. Rounding limits the accuracy of measurements under dry conditions (e.g., ±0.5% RH uncertainty corresponds to ±10% uncertainty in water vapor concentration for conditions of 5% RH). Also, this loss of information about the detailed vertical structure of the profile at low temperatures reduces the ability of a time-lag correction to recover the vertical structure in the UT/LS. Most archived data in the world are EDT format, which is unfortunate. A transition to the default use of FLEDT format is highly desirable for the benefit of future operational and archived data.
Don't apply the ground-check (GC) correction unless close attention is paid to the freshness of the desiccant and the reasonableness of the GC offset values. The GC procedure checks the sensor calibration at 0% RH during the launch preparation by placing the sensor in a container with desiccant that is assumed to produce an environment of 0.0% RH. The offset is optionally subtracted from the RH measurements to account for drift in the factory calibration during shipping and storage. It is apparent from scrutiny of many different datasets that too much GC correction is often applied, moreso for field campaign datasets than for operational datasets such as at ARM, presumably because operators are less experienced and procedures are less codified. Inattention to the freshness of the desiccant and the reasonableness of the GC values can result in a true environment in the desiccant container of several %RH, resulting in excessive GC correction and a constant dry bias throughout the profile, and also reduced accuracy of bias corrections because they are RH-dependent. The mean and standard deviation of the GC correction values for the 2006-2007 ARM RS92 dataset is −0.49±0.35% RH, and these are taken as reliable expected values because ARM maintains good operational procedures. I would consider GC values >1.5% RH to be suspicious and merit checking the desiccant freshness and the chamber seal, and GC values >2% RH almost certainly reflect faulty GC procedures or a bad radiosonde. Unless great care is taken with the GC procedures, it is advisable to apply zero GC correction and possibly accept a small moist bias rather than risk a potentially larger dry bias.
Save the RS92 RAW PTU data file (FRAWPTU) and the Vaisala database file (".dc3db") if possible. The RAW data file contains the pre-launch data acquired during the launch preparation, and also the measurements from both of the alternately-heated RH sensors, before the data are processed. Values below 1% RH or above 100% RH may be present in the RAW data, unlike the processed EDT and FLEDT files. The raw data are useful for evaluating the GC correction (negative RH values indicate an excessive GC correction or a bad sensor), and for evaluating any pre-launch comparison to reference sensors. The Digicora III database file allows the data to be reprocessed by simulating the sounding with different user settings if need be, such as with zero GC correction, or with "normal mode" processing rather than "research mode".
Compare the RS92 measurements to a reference-quality standard during the launch preparations, which gives information about the measurement accuracy under surface conditions. Besides characterizing the accuracy of individual radiosondes, a dataset of comparison measurements can be used to characterize the mean calibration bias and variability, as well as track the accuracy of radiosonde calibration batches over time, and it contributes to the development of empirical bias corrections. It is an area of on-going investigation to determine whether such comparison measurements at the surface can be used to apply a radiosonde bias correction for individual radiosondes (as opposed to a mean bias correction), especially for the less complicated T and P measurements. Note that I build something called a Temperature-Humidity reference system (THref) that is specifically designed for radiosonde comparisons but in general it provides high-accuracy reference measurements for an operational or research site.
Don't consider the minimum 1.0% RH values to be real. With standard "Normal mode" soundings, the Vaisala data processing sets all RH<1% values to RH=1% in EDT and FLEDT data files, so these values (mostly stratospheric) are artificial and should be filtered from analyses. It's easy to overlook this when doing, for example, remote sensor validations in mixing ratio space. Note that the raw data file (FRAWPTU), or the processed FLEDT data file in "Research mode" soundings, contain the actual RH<1% measured values if present, and also don't contain the (occasionally unreasonable) interpolations over "missing data" that is done by the Vaisala data processing in Normal mode. We generally use Research mode, but note that this requires some Data Quality Control as the noise and glitch filtering done in Normal mode is not done in Research mode. Note that the choice of sounding mode also has implications for the new Vaisala corrections applied with Digicora v3.64 software that was released in Dec. 2010 (see "Data Continuity issues" below).
The saturation vapor pressure (SVP) over liquid water (ew) as formulated by Wexler  is implicit in Vaisala's calibration and should be used when converting Vaisala RH measurements to other water vapor units or to RH with respect to ice (RHi), or when other water vapor measurements such as mixing ratio or frostpoint temperature are converted to RH for comparison to Vaisala measurements. The choice or assumption about ew is a source of uncertainty in water vapor measurements and calculations at low temperatures, where various ew formulations differ by up to 7% at -70°C (see Miloshevich et al. , Appendix A). Other radiosonde manufacturers (and other water vapor applications) likely assume a different ew formulation, which should be identified and taken into consideration. Note that the parameter RHi contains little uncertainty associated with the choice of formula for the SVP over ice (ei), because the common formulations all agree within 0.5% throughout the atmospheric temperature range.
Data Continuity issues with Digicora v3.64 software. In Dec. 2010 Vaisala began applying time-lag and solar radiation corrections in their standard RH data product, for only model RS92-SGP radiosondes and software version v3.64 on Digicora Sounding Systems MW31 and MW21. However, there is no indication in the data files that corrections have been applied. New and updated Digicora v3.64 software will apply the corrections but older software won't, and these can't be distinguished based on the data files. This is a nightmare situation for long-term climate monitoring, as it may make RS92 archives useless for trend analysis except at research sites where careful records are kept by knowledgeable people and then transmitted to data users who pay attention to them. Operational models may also behave unexpectedly if there is an unrecognized change in the data, and there could be double corrections if an external correction like mine is unknowingly applied to Vaisala-corrected data. Ideally the header information in data files would state the software version number and any corrections that were applied. Either zero, one, or both of the Vaisala corrections may be applied depending on the Digicora sounding mode (Normal vs Research) and the radiosonde model (K vs SGP), so these key parameters would ideally also be given in the header info, or at least should be recorded for each launch. The UTC launch time should also be noted, as well as the launch location (lat/lon) for K-type sondes without position information. One suggestion is to include the radiosonde model and the launch date and time in the filename, e.g. RS92_SGP.yyyymmdd.hhmmss.dat.
To summarize, an RS92 data file that is well-characterized and ensures data continuity and usefulness in the future should include the following information that is recorded and kept with the data file as meta data: radiosonde serial number (already present in header info), software version number, corrections applied or "none", sounding mode, radiosonde model, UTC launch date and time, and launch site lat/lon with <100 m precision.
The investigation of the Vaisala v3.64 software and corrections that led to the above Data Continuity conclusions was conducted by Dave Whiteman, Ricardo Forno, Scott Rabenhorst and myself, as an unexpected activity during the NASA-funded WAVES_2011 lidar validation campaign at the Howard University Beltsville Campus. After consultation with Vaisala we verified the following behavior of the v3.64 software and corrections. The corrections are only applied to RS92-SGP soundings (not RS92-K), but the last order date for RS92-K is June 2011 so this is a short-term issue. By default the time-lag and solar radiation corrections are applied for RS92-SGP soundings conducted in Normal mode, but in Research mode only the solar radiation correction is applied. The Vaisala corrections can be "turned off" using the Digicora SYSPAR/PTUEditing parameter "Use2010CalculationForTU" (default = "Yes"), which is shown but not explained in the Vaisala Technical Reference document M210489EN-J on page 39. Turning off the Vaisala corrections makes them "non-standard".
The question arises as to how Vaisala's new corrections compare to mine, as they are not the same. The two time-lag corrections are different implementations that are based on the same laboratory time-constant measurements, and initial results show that they compare quite well. Both solar radiation corrections are empirically-derived in different ways from different data, but the methods were compared both theoretically and as applied to soundings during the R&D phase, and found to generally compare favorably. My 2009 "clear-sky" solar radiation correction is only valid for daytime clear or near-clear conditions in the lower and mid troposphere (some cirrus is OK). I have an experimental treatment of clouds that is briefly described here. I cannot say how Vaisala treats clouds in their solar radiation correction. My method also applies a correction for mean calibration bias, which currently gives improved accuracy especially in the UT, but it will eventually become "out of date" unless updated.