130 likes | 240 Vues
This document discusses QA/QC protocols for Datawell buoys, focusing on real-time quality control tests, metadata descriptors, and calibration procedures. It highlights the unique features of Datawell buoys, such as their spherical design and sophisticated processing capabilities. The group aims to compile standardized recipes for various sensors before the QARTOD II publication, addressing challenges in data transmission, flag systems, and the necessity for consistent metadata. Key next steps include feedback collection and expanding QA/QC capabilities across other wave sensors.
E N D
IN-SITU WAVE GROUP Kent Hathaway, Moderator QARTOD IIFebruary 28 – March 2, 2005
Sensor selection • Datawell buoy QC chosen as example of a process to establish a QA/QC recipe • Our group will compile recipes for other sensors prior to QARTOD II publication
What is a Datawell buoy? • Spherical • Directional • Mooring – connected by bungee cord. • Surface following, with vertical accelerometer, compass, pitch and roll sensors • Vertical motion not susceptible to the pitch • No limitation on depth • Sophisticated processing inside • Protective triangle- protects from spinning during ship collisions.
1. What real-time quality control tests should be applied? Datawell transmits both an XYZ file and a spectral file Frequency domain: • Check Factors Test – ratio of vertical to horizontal displacement • Inclination Test • Period exceedence Test • Threshold Test- Hs, Tp, Dp, (SNR, Hrms, Tm, Dm) Time Domain: • Spikes, flat episodes, range, consecutive values, acceleration, mean test Quality of Telemetery: • Discontinuities in transmission • Data Corruption - CRC
2. What categories of real-time quality descriptor flags should be required? • Datawell uses own flag system, but these can be mapped to agree with QARTOD I system • -9= missing • 0= quality not evaluated • 1= bad • 2=questionable/suspect • 3= passed real-time QA/QC (as opposed to GOOD) • Distinction should be made between real-time flags and post-processing flags • Flags should be defined in metadata
3. What real-time metadata descriptors should be included? • Providers should stay attuned to the IOOS/DMAC evolution • Providers should work towards making headers available in FGDC compliant format on request • Examples of datawell headers are listed on pages 58-61 of QARTOD I Report • Will work with metadata initiative group to define header parameters.
4. What real-time calibration flags should be required? • Buoy is calibrated at manufacturer prior to purchase. Data provider should include calibration date and method, as defined by manufacturer, in metadata. • Pre-deployment verification (prior to each deployment): • bounce • compass • inclination • electronic checks • In situ verification (parameters returned with each data stream): • check factor • inclination
5. What common data formats should be required? • Datawell output permits mapping to any desired data format: • ASCII or binary • NetCDF • compressed • FM-13 and FM-65 • others
6. Additional requirements associated with DMAC? • Data providers should: • keep apprised of DMAC evolution • prepare to deliver dynamic data service based upon further specifications by DMAC • provide guidance to DMAC regarding transport protocols and formats for data transfer???
Describe key next steps and current roadblocks to developing and implementing an operational QA/QC capability. • Roadblocks • Lack of specifics in DMAC • Capacity for verification procedures among certain users • Developing QA/QC capability takes time and experience • Need standardization of XML tags • Data transport between regional organizations
Next steps • Undergo same exercise for other wave sensors such as pressure gauges, buoys, ADCPs, radar, HF • Email draft “recipe” and list of metadata parameters to rest of group to get feedback • Assemble matrix using this feedback