Did the aircraft instruments often go down during the project? I see on a number of flights that have only short periods of some measurements such as winds and temperature.

All parameters should always have values; however, when a measurement is not reliable, the missing value codes (MVCs) is the value. MVCs can result because a necessary measurements needed to calculate the parameter is not available (contains MVCs) or manual edits have been applied to place MVCs in the field because it is judged to be unreliable for some reason. An edit file is kept which contains the reason that an manual edit was made. (David Delene - July 19, 2006)

Did the Citation ever make true overpasses over the NSA site? I've done some calculations based on the NSA coordinates and pos_lat and pos_lon from the Citation and it seems that the aircraft typically only got to within about 2 km of the site but didn't really flight over it. Is this correct or are my coordinates/calculations off?

You need to ask Project's Flight Scientist for sure but I would expect that you are correct. The aircraft latitude and longitude parameters are a lot better that 2 km. (David Delene - July 19, 2006)

Which is the better measure of turbulence, “turb” or “turb_n”? Are differences between these due to air motions cause by the aircraft?

The “turb” measurements is made on the aircraft wing while the “turb_n” measurement is made on the aircraft nose. From the data I've looked at these measurements track very closely. I would suggest using the “turb” measurements because it is made using a long pitot tube out on the wing tip. The affects induced by the aircraft for the wing “turb” is most likely less than for the nose measurement. (David Delene - July 19, 2006)

Do you have measurement uncertainties for turbulence, vertical winds, and horizontal winds?

The turbulence calculation is for a certain size length which tries to match the turbulence you would measure from a radar. See Poellot M. R. and C. A. Grainger, A Comparison of Serveral Airborne Measures of Turbulence, Fourth International Conference on Aviation Weather Systems, June 24-28, pg 90-93, 1991 for more information about the turbulence calculation used.

Assuming the aircraft configuration is calibrated correctly, the horizontal wind components uncertainty is 1 m/s. See http://cumulus.atmos.und.edu/citation/winds/index.html for information on the Citation winds. I don't have a real good number for the vertical winds uncertainty but I would say between 0.1 and 0.5 m/s. If winds are important to a project, wind calibration data should be taken as part of the project to confirm that configuration changes have not affected the wind measurements. If no wind calibration data is available, the last calibration is used and it is assumed nothing has changed. (David Delene - July 19, 2006)

I have a question about the EG&G %RH field. Am I right in thinking that RH is always calculated from dewpoint and never from frostpoint? (I’m assuming that the calculations for %RH from dewpoint and frostpoint are different.)

The EG&G %RH field is based on the measured air temperature and the EG&G measured temperature. The EG&G measured temperature is a dew point temperature if dew collects on the mirror and a frost point temperature if frost collects on the mirror. Hence, the RH is with respect to water if the EG&G is measuring a dew point temperature and with respect to ice if the EG&G is measuring a frost point temperature. So the question becomes when does dew collect and when does frost. Dew collect above O C and frost below -40 C and some where in between it switches. Don't know exactly where, but it seems to be somewhere around -10 C. This is a good reason to use a TDL instrument to make humidity measurements. (David Delene - July 17, 2006)

Concerning your vertical wind velocity measurements, are these defined as positive in the upward direction or visa versa….

Positive is defined in the upward direction (David Delene - June 27, 2006).

What is the nature of the POS_Time field, specifically what’s its range and how useful is it?

The POS_Time field is the time from the Applanix Position and Orientation System (POS) which is based on GPS data. The POS_Time is in second from midnight on Sunday; hence you have a week worth of possible values. The problem with the POS_Time compared with the data system time is that you don't have a valid POS_Time until the Applanix POS locks onto the GPS satellite. You will always have a data system time but not the POS_GPS time. The accuracy of the data system time depends on how well the scientist set it before the flight (M200 data system). Typically it is within a one second; however, some flights may be off. The POS_Time, when you have it, will be as good or better than the data system time. A the new data system (m300_data_system) was acquired in the summer of 2005 which eliminates the need to set the data system time manually. (David Delene - June 9, 2006)

The date that the data was taken is listed in the header of each data file. Is this the local date or UTC date?

The aircraft data system uses UTC so the date is also UTC. (David Delene - June 9, 2006)

During a flight while data is being captured, what happens to the second-from-midnight (SFM) time when the UTC date changes? Does it roll over or keep going beyond 86399?

The SFM time is seconds from midnight on the day the flight started. Hence it goes beyond 86399. This is one of the things I've changed when I started working here. The idea of a non-continues time series for an aircraft flight is hard to work with. The file name prefix and start time within the data file may not always agree in cases where the time on the M200 data system was set incorrectly. For these flights there is a time adjustment applied during post-processing to correct for an incorrectly set data system time. We have eliminated this problem with our new m300_data_system (Summer 2005) which uses GPS based time sync. so that the time does not have to be set manually. (David Delene - June 9, 2006)

Does the .tam extensions on these files refer to TAMDAR? Or is it just a coincidence?

The “tam” extension represents an ordered list of parameters than was put together when UND first started working with the TAMDAR probe. This was before I started working with the Citation data in 2002. Anyway, I have my data processing process broken up into data levels. Level 0 is the raw binary data taken on the aircraft. Level 1 are binary files that have been separated into different files usually by instrument. Level 2 are ASCII data files for each instrument where engineering units have been converted to physical units. Level 3 are ASCII data files where measurements from different instruments have been combine to calculate things like True Air Speed or Ambient Temperature. Level 4 data combines Level 3 data to create things like combine spectrum. The same standard data file formats are used on all projects and files are created based on what instruments were on the aircraft. Different users need a combine data file with parameters of interest; hence I create a file for each user that takes parameters from the different standard file formats (Level 2, 3, 4 data files) to create a user file format. The *.tam file is AirDat's user file format. For some project I create several different user files and several projects have the same user file created. (David Delene - June 8, 2006)

Actually, why use IDL for data processing and visulation of the aircraft data? Why not use C or C++? I’m not much of programmer so keep it simple.

The reason to use IDL instead of C++, FORTRAN, JAVA is code development time. You can create working programs in IDL 10 time faster than in something like C++. This really makes up for the licensing cost. IDL is similar to MatLab but can handle satellite data better. C is good for code that needs to run fast (i.e. weather model), IDL is good for generating working software fast. (David Delene - June 7, 2006)