For this page:
THE NERC MST RADAR FACILITY AT ABERYSTWYTH
Error in MST Radar altitudes (and ranges) for the period 6th
February 2007 - 8th April 2008
Owing to a bug in the new MST radar control and data acquisition system, there have been errors in the reported ranges and altitudes of all MST radar data products for the period from 13:44:03 UT on 6th February 2007 until 14:37:00 UT on 8th April 2008, inclusive.
A compensation for this problem was introduced into the signal processing software starting with the cycle/dwell beginning at 12:48:15 UT on 7th February 2008. Click here for more details. However, it turns out that this over-corrected the problem. Moreover, this meant that the data at the lowest three range gates were unreliable.
The problem has now been fully understood (for the ST-mode) and solved. Appropriate changes were introduced to both the data acquisition software and the signal processing software for cycles/dwells starting at, or after, 14:50:03 UT on 8th April 2008.
Cartesian and radial files for the period 6th February 2007 - 8th April 2008 (inclusive) will eventually be recreated with the corrections incorporated, However, until then, data users should apply the compensations shown below. If you have any doubt as to whether or not your files are affected, or as to how to carry out the compensation, please contact the NERC MST Radar Facility Project Scientist directly.
This page covers the following topics:
How to tell if your files are affected
For the time being, all files containing data for the period 6th February 2007 - 8th April 2008 should be considered to be affected. However, when the data are eventually reprocessed, the compensated
are after 9th April 2008 (2008-04-09). Files are typically created a few hours after the 24 hour period which they cover. It is likely that the spectral files will be left as they are and users will need to apply the corrections themselves.
How to compensate for this error in affected ST-mode data
Dates and times below are given in the format YYYY-MM-DD HH:MM:SS. The bottom and top range gate numbers are recorded in the Cartesian and radial files by the global attributes data_bottom_range_gate_number and data_top_range_gate_number, respectively. Spectral files can store ST-mode and M-mode data simultaneously and so have variables (rather than global attributes) named bottom_range_gate_number_for_ST_mode, top_range_gate_number_for_ST_mode, bottom_range_gate_number_for_M_mode, top_range_gate_number_for_M_mode.
How to compensate for this error in affected M-mode data
If you are making use of M-mode data, even for periods unaffected by the range problem, please contact the NERC MST Radar Facility Project Scientist.
The legacy documentation is incomplete, and sometimes ambiguous, in regard to the M-mode range gates. Moreover, there is reason to believe that there are (slight) bugs in the original data acquisition software. Consequently a solution to the ranging problem has been based on second-guessing what was intended rather than what was implemented in the original software. It is anticipated that any errors in range are less than 1 km. Unfortunately there is no independent method of verifying the altitudes of M-mode range gates.
It is known that a hardware pre-processing unit prevents data from the middle range gates, nominally numbers 192 - 385 (i.e. a gap of 192 gates), from being passed to the data acquisition computer (since no useful radar returns are expected from this altitude region). It is also known that the number of the lowest recorded ST-mode range gate is determined by half the transmitted pulse length, i.e. range gate number 4 for standard 8 us observations, and is not 0 (as was expected). It seems likely that the same offset would apply to the M-mode so that the two altitude ranges are still separated by 192 range gates. The hardware range gate number is therefore related to apparent range gate number through the relationship:
2 hardware_range_gate_number = apparent_range_gate_number - m_mode_range_gate_offset
For dwells/cycles starting before 2007-02-06 13:44:03 UT (i.e. using the original data acquisition system), the following was assumed:
m_mode_range_gate_offset = 190
For dwells/cycles starting between 2007-02-06 13:44:03 UT and 2008-02-07 11:54:57 UT, the following was assumed:
m_mode_range_gate_offset = 194
For dwells/cycles starting after 2008-02-07 14:37:00 UT, the following has been assumed:
m_mode_range_gate_offset = 192 + int(length_of_transmitted_pulse_length_in_us/2)
i.e. m_mode_range_gate_offset = 196 for standard observations with a pulse length of 8 us. The range gate translation is carried out by a PROM, which will need to be investigated before any progress can be made on this. Owing to the lack of correlative data, there is no easy way to verify this any more at the present time.
Evidence for the problem
The fact that there was a problem became apparent almost as soon as the new radar control and data acquisition system began operations in February 2007. The monthly comparison statistics of wind-profile data against the Met Office model fields showed:
The second plot shows the relationship between radiosonde-derived and radar-derived wind speeds assuming an offset of +4 range gates.
Page maintained by
Last updated 16th April 2008