EC Raw Binary Format (CH-LAE)

Last update: May 8, 2023 @ 11:35

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) SA: “axis” orientation

(2) 2 extra bytes in data stream Note 19 Oct 2018 (LH): I am not sure what the problem here was, data look like they have the same structure despite the 2 extra bytes mentioned. Needs check in case of recalculations. For now, this is listed as the same format as 2015-3.

(3) QCL: ver1 var0

(4) correct # of bytes

(5) (1) For some reason 2007 is a special case, because using the Horst (1997) spectral correction yielded unrealistic results, i.e. the spectral correction factor for CO2 was far too high (up to 11 instead of 1.05). Therefore, this year was calculcated using the spectral correction by Massman (2000, 2001). This was a problem only with EddyPro version 521, Flux Run v2015-03, and was solved in later versions of EddyPro.

(6) QCL: ver1 var2

(7) QCL: ver1 var2 EMPTY

(8) 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 Licor 7200 running.

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

(13) From now on: 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) 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 can be directly done during the conversion of the raw data binary files to CSV files when using the FCT Flux Calc Tool. Note the provided EddyPro settings under Downloads at the end of this page: these settings already consider the correction and apply the gain to the CO2 concentration measurements during the conversion from raw binary to CSV. 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) 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) 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.

Downloads

–