4 Responses to Software version missing as meta data in operational radiosonde data transmitted through the GTS?

  1. The Vaisala RS92 data continuity issue described above concerns the lack of a software version field in the meta data that is transmitted to operational or climate data centers using the TEMP or BUFR format, where the software version is ONE FACTOR that prevents robust traceability of the characteristics of the radiosonde sensor and processed data. In particular, Digicora v3.64 software applies solar radiation and time-lag corrections in the standard data products, but there is no indication that corrections have been applied in the meta data or the data files (only in the dc3db database file). There are two other factors worth mentioning.

    1. The v3.64 corrections are applied differently depending on the sounding mode (Normal vs Research) and the radiosonde model (RS92-SGP only). No corrections are applied for RS92-K radiosondes (to be discontinued soon). For RS92-SGP sondes in Research mode, only the solar radiation correction is applied and not the time-lag correction. Furthermore, it is possible to “turn off” the corrections by changing a default Digicora setting to “No”. Further details about this data continuity issue are on my radiosonde webpage at the above link. I’m not familiar with the TEMP and BUFR messages, but certain knowledge of the corrections that were applied (or “none”) requires knowing the software version number, radiosonde model, sounding mode, and value of the Digicora setting “Use2010CalculationForTU”.

    2. Much RS92 data that is used for research does not reference meta data but only the data in the sounding data file (EDT or FLEDT). For example, field campaign datasets, or RS92 data downloaded from the ARM archive, are just the FLEDT data files with header information. That is, much research is done without consulting meta data or database files (even if they exist), so these data continuity issues are raised not due to the TEMP and BUFR messages but because the corrections-related parameters are not present in the header of FLEDT and EDT data files. While this doesn’t affect GRUAN data directly, future analyses based on standard RS92 data files will be in doubt. For full future usefulness, data file headers would also contain the site lat/lon/alt and the UT launch time.

  2. Alexander Kats says:

    Indeed, when we speak about FM-35 TEMP there is no mean to receive extended metadata except their offline collection. It seems, state-of-the-art of collecting upper-air metadata even for the GUAN network, which is according GCOS-73 “must have”, is not sufficient. Even IGRA metadata (http://www.ncdc.noaa.gov/oa/climate/igra/index.php?name=metadata) likely lacks this sort of information.
    But regarding transmission upper-air messages in BUFR it may be not the case. According to information, I got through CBS IPET-DRC activity, since DigiCORA III version 3.61 Vaisala introduced options, allowing beside others including additional metadata parameters such as
    001081 Radiosonde serial number [CCITTIA5]
    001082 Radiosonde ascension number
    002067 Radiosonde operating frequency [Hz]
    002095 Type of pressure sensor [Code]
    002096 Type of temperature sensor [Code]
    002097 Type of humidity sensor [Code]
    025061 Software identification and station number [CCITTIA5]
    205060 Information on the reason for termination of the sounding (in plain text).
    For example, in provided example 025061 was “MW31 3.61” and 205060 was “Increasing pressure”. I don’t know details about managing these options – may be via Windows Registry or DBManager, but I expect they could be readily advised by Vaisala.
    However, as Dr. Miloshevich explained, knowing software version only is not sufficient. Potentially, BUFR do has a capability to include required metadata but it requires doing some work from upper-air data users community (e.g. GCOS), IPET-DRC, Vaisala and upper-air network management.

  3. Tony reale says:

    Holger sent me an email concerning this thread

    Is there any information as to the date when the new processing algorithm was installed for GTS data; has it been installed for GTS sondes?

    Larry, I did not see your radiosonde web page link (I’ll look for it…)

    At this time our validation system here at NOAA, NPROVS, reports the following RS92 processing systems available:
    DigicoraI,II or Marwin (Finland
    Digicora III (Finland)
    Autosonde (Finland)

    Does the new processing algorithms apply to all?

    I will see if we detect a change (and magnitude)using our real-time validation (NPROVS) system. We have previous results documenting dry bias for most sondes (Russian sondes a notable exception).

    will follow-up


  4. Tony,

    The link to my radiosonde webpage is my name in the above message. There are relevant links under “RS92 Data Continuity”, one of which is our own experiences with the v3.64 software at:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: