EC Raw Binary Format (CH-LAE)

See here for more info about the EC raw binary format.

Legend

An overview of used abbreviations can be found here: Abbreviations

Setup since 2004

Notes

(1) QCL: ver1 var0 (with N2O, CO2, H2O) according to Table 3 in sonicread_20190503.pdf. However, it seems that the CO2 measurements from the QCL are wrong according to this note in qcldoc_20200515.pdf, p5: “It turned out that the CO2 concentration data were erroneous since a wrong absorption line had been chosen (the one for 13CO2).”

(2) 2 extra bytes (dummy) in QCL-L2 data (data size 16 Bytes). It is possible that QCL data during this time period did not produce usable data. It was not possible to convert the gases listed in (2) to proper units.

(3) correct # of bytes (data size 14 Bytes)

(4) QCL measured isotopes: ver1 var2 according to Table 3 in sonicread_20190503.pdf

(5) SA orientation is possibly 206° from here on until now. In case of recalculations, please check.

(6) QCL data empty, but still part of the datastream. Sends empty data.

(7) –

(8) ISSUE: SHIFTED TIMESTAMP: There was (is?) an error in the raw binary filename timestamp between 2013-07-06 and 2013-07-12. Relevant fieldbook entry: “2013-07-12: time on moxa was wrong. changed on 16:44 from 22:43:50 to 15:44”, i.e. 6 hours + I renamed all files from 2013070615.b02 until (incl.) 2013071214.b00 manually by subtracting 6 hours. For example: 2013070802.b00 was renamed to 2013070720.b00. In case of flux calculations it needs to be checked if the time error still persists.
During the generation of the PI dataset CH-LAE FP2021 (2004-2020) this error still needed correction after fluxes were calculated: “In the IRGA75 Level-1 fluxes, the timestamp of flux variables between 6 Jul and 12 Jul 2013 (6 days) was shifted by approx. 14.5 hours. Affected time range: between 2013-07-06 15:45 and 2013-07-12 23:45. For example, data at timestamp 2013-07-06 15:45 is really 2013-07-06 08:15. Level-1 data were shifted accordingly. Then, the transition day 2013-07-12 was set to missing.”

(9) Removed IRGA75 from site on 2017-12-12, see entry in GIN.

(10) IRGA75 is not on site anymore, but still part of the data stream, i.e. logged data for IRGA75 are empty.

(11) IRGA75 is now removed from the data stream. Since Wed Jan 31 11:25:37 2018 we only have the IRGA72 running.

(12) –

(13) ADDITIONAL ARTIFICIAL LAG TIME: In addition to the normal lag time between IRGA and sonic we have an artificial lag time of 12 seconds due to the buffer, which needs to be considered when processing the files when searching for the best correlation between vertical wind speed and CO2/H2O concentration. For more info see here. This also affects all following time periods.

(14) IRGA72+ installed, IRGA75 was removed from the site. IRGA72+ has now 13 columns instead of 12 columns. New: diag_val and signal_strength. Not logged anymore: status_byte.

(15) ISSUE: WRONG CALIBRATION GAS: There was an issue with the calibration gas used to calibrate the IRGA72. As a consequence, the CO2 concentrations in the raw data files have to be multiplied by 0.974 before flux calculations. This is done directly during the conversion of the raw data binary files to CSV files when using bico and selecting the appropriate IRGA IRGA72-B-GN1. For more info about this issue see here: Wrong Calibration Gas 2017. Affected time period: all IRGA72 CO2 concentrations between 2017121417.L22and 2019031523.L20.

(16) IRGA75 temporarily installed as replacement for the defective IRGA72. The IRGA75 is not affected by the calibration gas issue described in (15). IRGA72 was dismounted and removed from site. However, I found this info on GL-PROCESSING (in the fluxes Level-0 folder): “Problems with LI-7200 starting on December 22nd 2018. Replaced by LI-7500 in January 2019. The LI-7500 consistently displays IRGA AGC too low and there seems to be a problem with the fluxes. LI-7500 replaced on March 20 2019 with the LI-7200, and the fluxes are back to normal.” (written by unknown)

(17) The IRGA72 was replaced with another IRGA72 on 11 Jan 2019, the data stream is the same. However, it seems like both IRGA72 were defective. In this time period, there are mostly incomplete files and it is possible that no reasonable fluxes can be calculated.

(18) From now on: The calibration gas issue described in (15) is now solved, the correct gas was used this time.

(19) ISSUE: LOW IRGA72 FLOWRATE: During this time period there was an issue with the IRGA72: no clear lag time could be found (tested in search windows 0-20s and -50 to +50s) in contrast to the period before and after. On 7 Jun 2018, the flow module of the IRGA72 was replaced and after the replacements lag time detection again worked as expected. It is likely that the IRGA72 flow module was broken. It is recommended not to use the following fluxes: CO2 fluxes between 19 May and 6 Jun 2018, and water fluxes between 13 May and 6 Jun 2018.

(20) ISSUE: TRANSITION PERIOD: This is the transition period where the new IRGA72 was installed. There are several issues with the IRGA72 data:

• Do not use IRGA72 data: between 2016011115.b05 and 2016012207.b00: Transition phase during the installation of the new IRGA72.
• Mostly good IRGA72 data: between 2016012213.b00 and 2016030107.b00: The regular IRGA72 data acquisition started on 22 Jan 2016. However, there are some shorter drop-offs in the flow rate.
• Do no use IRGA72 data between 2016030113.b00 and 2016052601.b00: During this phase, the CO2 and H2O fluxes from the IRGA72 are very low and look very different from the IRGA75 fluxes during the same time period. According to the fieldbook on GIN on 26 May 2016: “quite a lot of water was in the filter right before the flow module (after the IRGA cell)”. The issue was with the IRGA72 flowrate which is very low (approx. 2 L min-1, checked in raw data) between 2016030113.b00 and 2016052601.b00.

(21) From now on, IRGA72 data look fine.

(22) UNKNOWN FORMAT: Data were logged in an unknown format, at the time of writing this was still not resolved (Jun 2023). It is possible that all the data are indeed corrupted. When trying to convert these data using the script ethconvert (script is running on the server) I get the message: “ethconvert Version 6.03 (Date 2018-09-25), File is expected to be in WECOM3 or RCOM3 format, file_type is 0xc9, this is a WECOM3 v2 data file, file_type changed to 0x49, file type binary data, with IRGA data. 0 analog channels in use. IRGA with record length 44 not known. Exiting.” This IRGA record length of 44 Bytes was also confirmed during a test conversion using the script bico. However, an IRGA format that sends 44 Bytes of data is unknown also in bico. -LH

(23) NEW IRGA INLET POSITION: IRGA inlet changed to new position. The change happened between 15-17h, the file 2023031319.L00 is the first complete file with the new inlet position.

Downloads

–

Last Updated on 18 Feb 2024 22:13