ESA Earth Home Missions Data Products Resources Applications
    24-Jul-2014
EO Data Access
How to Apply
How to Access
Index
Credits
RA2/MWR Data Formats Products
Glossary
Frequently Asked Questions
Main RA-2 Level 2 Algorithms (Non-Ocean)
Main MWR Level 1b algorithms
Main RA-2 Level 1b algorithms
MWR Instrument
RA-2 Instrument
RA-2 and MWR Instruments
MWR Instrument Characteristics and Performance
In-flight performance verification
MWR Instrument Description
RA-2 Instrument Characteristics and Performance
In-flight Performance verification
RA2/MWR Products and Algorithms
RA-2/MWR Auxiliary files
Common Auxiliary Data Sets
Level 2 processing
Level 1b processing
Specific Topics Related To The Radar Altimeter
Orbit interpolation
Measurement Reference
Datation
Time Handling And Leap Seconds
RA-2/MWR Level 2 Products And Algorithms
RA2/MWR Level 2 Products
Averaged Ku chirp band
Ocean depth/land elevation
RA-2 ionospheric correction
RA-2/MWR Level 1b Products and Algorithms
RA-2/MWR Level 1b product
MWR Level 1b algorithms
Level 0 products
MWR Level 0 products
Products Evolution History
Definitions and Conventions
Organisation of Products
Data Handling Cookbook
Characterisation And Calibration
Latency, Throughput And Data Volume.
Product size
RA2/MWR Products User Guide
Further reading
How to use RA-2/MWR data
How To Choose RA-2/MWR Data Products
Summary of Applications vs. Products
Peculiarities of MWR
Peculiarities of RA2
Geophysical Coverage
Principles Of Measurement
Scientific Background
ENVISAT RA2/MWR Product Handbook
Services
Site Map
Frequently asked questions
Glossary
Credits
Terms of use
Contact us
Search


 
 
 


2.6 RA-2/MWR Level 1b Products and Algorithms

2.6.1 RA-2 Level 1b algorithms

The key processing algorithms required for the generation of the L1b product starting from the RA2 Level 0 product are:

  • Level 0 data decoding
  • Orbit Data generation and datation correction
  • Point Target Response data processing
  • IF shape correction
  • Window time reference extraction
  • Automatic Gain Control calibration
  • Level 1b data formatting

 

The Level 0 data decoding and PTR data processing are called once very source packet analysed. The Level 0 data decoding is also in charge of providing information from the 20 DBs of the ISP analysed to the IF shape correction, Window Time reference extraction, AGC calibration and Orbit data generation functions which operate on single DB basis.

The Output Data packaging function operates on single DB basis for the information relative to individual DBs, and on ISP basis for the information retrieved from the PTR analysis and individual echoes data.

2.6.1.1 Level 0 data decoding

The Configuration file, the Characterization file, the Calibration files, the Constant and Orbit State Vector files and the Level 0 data are handled by this function. Configuration and Characterization informations are extracted from the corresponding file to setup the processor and the processing constants (i.e. configuration parameters and characterization parameters).

Each field of each Source Packet contained in the raw data stream (Level 0) is extracted and converted to engineering units according to its binary format (signed/unsigned integer or floating point C2 format) and the value and physical dimensions of the least significant bit.

Whenever possible, integrity of decoded parameters is verified by means of dedicated consistency checks and warning flags set accordingly. In some cases, when no suitable way of verifying the data integrity during the decoding phase is available, consistency checks are performed throughout the Level 1b processing on the parameters computed from the original quantities extracted from the source packet.

 

The main processing steps performed within these functions are the following:

  • Computation of the effective IF calibration mask: to be used during the processing: this is done by using the value of the IF mask selection flag and the RF redundancy flag from the Configuration file and the IF (flight or ground) mask from the IF auxiliary file.
  • computation of the effective USO calibration value: to be used during the processing: this is done by using the value of the USO selection flag from the Configuration file, the flight USO Tx/Rx clock value from the USO aux. file or the ground clock value from the Characterisation file.
  • Decoding of FEP annotations in the L0 DSRs: a summary error flag is generated from this check and exported into the RA2 L1b MCD check of the ISP packet length: a flag is generated (errors encountered or not) and exported into the RA2 L1b MCD.
  • OBDH datation consistency check: the difference between consecutive OBDH datations is calculated and compared with respect to a tolerance (maximum number of clocks elapsed between consecutive ISPs). If the difference exceeds this number, the OBDH flag is set and reported in the output MCD. NB: the OBDH datation is not modified in the event of OBDH_flg=1, so as to avoid the propagation of wrongly corrected OBDH values for the whole product. It will be the end user who will discriminate, using this flag, which one was the ISP with the wrong OBDH datation
  • On board binary to UTC time correlation: the ICU clock counter datation (OBDH) is converted into UTC datation for each DB, using a UTC reference time. This reference time will be leap second corrected, if relevant, before being used in this algorithm.
  • Redundancy flags decoding: the values of the RFSS and HPA redundancy flags from the ISPs are checked against default values from the Configuration file. If discrepancies are found, a warning flag will be raised and exported into the output MCD
  • corrected Noise Power Measurement computation: the input NPM value is corrected through a scaling factor extracted from the Configuration file
  • corrected Automatic Gain Control of Noise Power Measurement computation: obtained from the AGC table for NPM in the Characterisation file, and the AGC_NPM value from the L0 data
  • DFT indexes evaluation: the DFT indexes are decoded from the L0 ISPs and used to compute the final DFT indexes that will be exported into the output product.
  • USO datation consistency check: the difference between consecutive USO datations is calculated and compared with respect to a tolerance (maximum number of USO datation values between consecutive ISPs). If the difference exceeds this number, the USO flag is set and reported in the output MCD. NB the USO datation is not modified in the event of USO_flg=1, so as to avoid the propagation of wrongly corrected USO values for the whole product. It wil be the end user who will discriminate, using this flag, which one was the ISP with the wrong USO datation
  • Setting of fault_id flag: the fault identifier is read from the L0 DBs, and then the L1b output MCD fault_id flag set to 0, if all decoded bits are 0, meaning that no errors have been detected on board, or set to 1 otherwise.
  • RA2 alignment processing: this processing step is aimed at correcting for the time lag existent in the RA-2 on board processor between the echoes accumulation and echoes processing. To do this, some information from a DB (i.e. Rx_dist_c, Rx_dist_f, AGC_c1, AGC_c2, AGC_f, AGC_Dist, AGC_Rate, HTL_Dist, HTL_Rate, n1_star, n2_star and Chirp_ID) is used to process the waveforms of the subsequent DB. If the previous DB was not Tracking, Preset Tracking or Preset Loop Output, but the current DB was in one of these modes, the mode id of the current DB is set to align failed to indicate failure in the alignment procedure. This happened every time there is an acquisition sequence.
  • Computation of the UTC time tag of the PTR measurement: this is done by using the PTR datation from the ISPs calibration field, the USO datation from the L0 ISPs and the satellite on board clock frequency from the MPH.

2.6.1.2 PTR Data Processing

PTR data measurements are processed in order to retrieve the relevant correction factors required to compensate for the variability of instrument errors.

New calibration data is computed from every ISP by properly processing the PTR samples in the calibration field. Only data from ISPs in mode_id= Tracking, Preset Tracking or Preset Loop Output will be considered meaningful and shall be processed. The value of the cal_band_id is used to verify that the data in the calibration field is effectively filled in, and to check the band (20, 80 or 320 MHz for Ku, or 160 for S) the data is associated with.

Computed calibration data from single PTR measurements are then checked versus allowed predefined ranges from the Configuration file. The computed calibration factors, if valid, are then used to correct the measurement data (AGC and window delay values).

When a Ku PTR is processed, the computed values are transferred to the Ku filtering units while dummy values are transferred into the S buffer, and vice versa.

Each filtering units is constituted by a couple of memory buffers in which calibration data from single PTR measurements, the relevant auxiliary information and validity flags are filled in, every time throwing away the oldest values in the buffers, once the buffers are full.

The relevant source sequence counter information extracted from the packet header, is also stored in the buffers in order to check the time lag between the first and last calibration data available.

Smoothed calibration values will be generated by averaging over the meaningful data contained in the buffers under the condition that the time difference within the last and first meaningful calibration data in the buffers does not exceed a predefined time duration. This test is required since time gaps in the Level 0 raw data stream may still be present and is performed by analysing the source sequence counter.

The main steps during the PTR processing are detailed here below:

  • FFT and square modulus extraction: from the In-Phase and Quadrature samples of the instrument PTR extracted from the source packets, an FFT (zero padding technique) followed by a square modules extraction is performed.
  • computation of time flight calibration factors: the position of the PTR maximum of the FFT filter bank allows to compute the flight calibration factors (for Ku and S) for the time delay measurement.
  • consistency check on these factors: these factors are checked against expected ranges from the Configuration file. If they are out of the allowed ranges, the factors are properly flagged to avoid their use in the evaluation of the smoothed calibration parameters
  • computation of the total PTR power: the total power of the PTR signal is computed using the In-phase/Quadrature complex samples of the PTR and calculating the sum of their squared modulus values.
  • evaluation of the amplitude correction factors: they are evaluated by using the total power, the PTR reference power and AGC used in ground characterisation phase to retrieve the reference PTR power, stored in the Charcaterisation file, and the AGC used for the PTR calibration, that is derived from the coarse AGC attenuation values from the calibration field.
  • consistency check on these factors: these factors are also checked against expected ranges from the Configuration file. If they are out of the allowed ranges, the factors are properly flagged to avoid their use in the evaluation of the smoothed calibration parameters.
  • population of the Ku/S filtering units: the computed time and amplitude correction factors will be included in the Ku or S filtering units, along with a combined quality flag that will be set to valid, only if both, time and amplitude correction factors, are in the allowed ranges.
  • averaging of the meaningful measurements contained in the memory buffers of the filtering units: the meaningful measures will be averaged considering that the time lag between the first and last meaningful measurements in the buffers does not have to exceed a specified amount expressed in terms of multiples of the equivalent time duration of a source packet.
  • retrieval of the final calibration correction factors: they are obtained from this averaging process if the number of valid measures in the memory buffers exceeds a minimum value (from the Config. file), otherwise, default ground values (from the Charcterisation file) will be exported into the output L1b product (i.e. L1b RA2 MDSRs and PTR MDSRs).

2.6.1.3 IF Shape Correction

This function implements the correction of the waveform samples for the IF filter shape distortions. This function is activated only in mode Tracking, Preset Tracking or Preset Loop Output, since only in this case the waveform samples are meaningful.

A preliminary check to verify that the whole set of Ku/S samples is not equal to zero is done before processing. Only the non-null samples set(s) will be IF mask corrected.

The correction consists mainly in correcting each Ku/S waveform sample by the corresponding sample of the effective correction mask to be used. This mask has been properly modified to account for the amount of fine shift applied to the waveforms in the on board processing. In fact, IF shape compensation is really effective only if the IF correction mask samples are rearranged to account for the same amount of shift.

The main steps in this task are the following:

  • consistency check on the waveform samples: if Ku (or S) samples are all null, the Ku (or S) waveforms are not IF corrected
  • evaluation of the specific correction mask in terms of fine component Rx_dist_f of the on board Rx delay, chirp bandwidth and chirp_id flag
  • correction of the L0 waveform samples by the calculated IF mask
  • S-Band anomaly flag evaluation

2.6.1.4 AGC Calibration

The on-board AGC measurement is corrected by the characterization corrections extracted from the Characterization Auxiliary File to provide AGC corrected values for Ku and S data. Any gain variation in the radar Tx/Rx chain with respect to the nominal condition characterized on ground is compensated using flight calibration data derived from PTR measurements. The power scaling factor required to evaluate the sigma_0 in the level 2 processor is additionally evaluated.

The main steps to be followed in this processing task are listed here below:

  • correction of on board AGC value for instrument errors: the AGC coarse values (AGC_c1 and AGC_c2) and the fine AGC_f value are combined and used in the AGCtable from the Characterisation file to obtain a unique AGC_sig value. This value, together with the ground amplitude calibration factors (from the Characterisation file) and PTR derived amplitude correction factor will be added to obtain the corrected AGC value
  • The total amount of calibration correction on the AGC is also computed and exported into the output L1b MDSRs
  • the power scaling factor needed for the sigma_0 evaluation at level2 is finally computed using the corrected AGC value, the overall gains of the receiving chain (extracted from the Characterisation file) and the chirp bandwidth

2.6.1.5 Window Time Reference Extraction

This function evaluates the time tag of the processed waveforms (Ku and S) from the Rx delay coarse and fine components computed by the on-board tracker and corrects it for instrument errors and Doppler shift.

The following processing steps are performed within this task:

  • computation of the on board Rx delay (separately for Ku and S) from the Rx coarse and fine components extracted from the DBs of the Source Packet. The on board measurement is further compensated for the PRI ambiguity rank, for the height rate and converted to time units using the Tx/Rx clock period
  • the computed Rx_del_Ku/Rx_del_S values are tested against expected ranges (min/max values from the Configuration file), and a warning flag is raised if the computed values are out of these ranges
  • the time delay measurements are corrected for instrument induced errors using both ground(from the Characterisation file) and in-flight (from PTR) calibration parameters
  • the Doppler effect caused tby the satellite radial velocity is compensated by adding the Doppler correction factor to the time (or window) delay

2.6.1.6 Orbit Data Generation and Datation Correction

This function provides the calculation of latitude/longitude coordinates for each processed data block in the source packet and the needed spacecraft orbit parameters. Data are retrieved through the EnviSat Orbit computation library that uses data from the Orbit State Vectors files. Furthermore it operates datation correction for propagation delay.

These are the main steps within this function:

  • orbit function call in initialisation mode and propagation calls for every DB time. From the propagation calls, only the output satellite height is kept
  • This value of Height is used to obtain the propagation delay, and then used to correct the UTC of every DB
  • The updated UTC_DB time value is used as input for a second orbit function call (in propagation mode), and the latitude, longitude, Height and Height rate will be retrieved and exported into the output product

2.6.1.7 Level 1b data formatting

The processed RA-2 data, as well as MWR shall be packetised in the L1b product format.

The MWR processed data will be exported into the L1b MWR MDSRs, while the RA2 processed data will go to the first (main), second (individual waveforms) and third (PTR) MDSRs.

The individual waveforms in the 2nd MDSRs are a copy of the individual echoes contained after the L0 ISPs, when present. The OBDH datation in every individual waveforms record is a copy of the OBDH value of the ISP that contained the individual echoes, while the record time corresponds to the first DB of the source packet containing these echoes.

 

In general, the information to be exported into the L1b records will come from the functions that operate on a DB or ISP basis, and will be copied in the 20 L1b records output from the same ISP (if information is not DB dependant) or updated for every output record, if the record frequency is 18 Hz.


Keywords: ESA European Space Agency - Agence spatiale europeenne, observation de la terre, earth observation, satellite remote sensing, teledetection, geophysique, altimetrie, radar, chimique atmospherique, geophysics, altimetry, radar, atmospheric chemistry