Local links to various topics: | Temperature
| Time | Altitude |
MJ: Is your Calculated OAT available in realtime? I read in an old email that you think that it is more accurate than SAT which Collins quotes at 1.6 K rms, although as you pointed out, the recorded resolutions is much better, so this might be a worst case number, with real performance being better. (Are you impressed with the length of this sentence and my lack of respect for the English language?)
NGC: (I'm a big fan of the run-on sentence myself...) Okay, here goes:
DADS SAT and Calculated SAT are both available in real-time, and are both contained in the "E" block in the data stream. As you know, SAT is a direct readout from the Collins unit; calculated SAT (also called SATC or SATM sometimes) is derived from Mach # (also from the same Collins unit) and Total Air Temp (from a Rosemount probe). For SAT, the Collins unit uses it's own TAT probe and internal calculations, for SATM we use a different TAT probe and do the calculations ourselves. Also, for SATM we use TAT averaged over one second (10Hz sampling, slightly skewed unfortunatley since the acquisition is at about 0, 100, ...900 msec during the one-sec cycle) and the Mach value closest to the mid-point of the one-sec cycle.
FWIW, we keep all the raw data acquired, which includes SAT from 2 air data computers (output at ~2.5 Hz, but sampled by DADS at 4 Hz, Mach from both air data computers (output at ~8 Hz I think, and sampled by DADS at 10Hz), TAT from both air data computers (output ~2.4 Hx, sampled at 4Hz) and TAT from the Rosemount probe, acquired at 10 Hz. It all seems to be fine data, no post-processing (aside from extracting it from the big binary files) needed; there is the possibility of regenerating all of this into a sea of SATs for more analysis, although it would take a little work.
MJ: What is the prefix of the DADS Archive files? (We've never used them!) Does SAT ever change in the archive compared to realtime? Do you have any reason to believe that OATcalc is better than SATrealtime?
NGC: It's dm and dp, ones more lat/lon and the others more SAT/hygrometer type stuff. No, SAT never changed compared to real-time; I can image a case where an air data computer dies or a TAT probe ices up, and we have to regenerate the data from the spare DADS inputs afterward, but I'm pretty sure that didn't happen during SONEX.
I do have reason to believe SATM (OATcalc) is better than SAT; one of the main reasons is conversations with Bruce over the years, where he has mentioned that SATM seems to always match MTP and other independent data better than SAT. The two seem to usually be apart by about .6 or .8 C or so (my obs). I recall other PIs telling me SATM was truer that SAT as well, but I can't recall who it was, darn it. Except I think Andy Heymsfield looked into it once also.
I recall Bruce telling me this both before and after the DC-8 air data computers were upgraded (back in 94 I think), which leads me believe that (since the upgrade didn't affect the difference) it has something to do with the positions of the various TAT probes on the nose.
MJ: Finally, for SONEX MTP applied a -0.8 K correction to realtime SAT (aka DADS OAT) to do gain calibration. Curiously, Steph sees about a 1 K difference between the archived SAT and archived calculated SAT, with the latter being smaller. This sort of suggests that your calculated SAT may in fact be better than the ADC realtime SAT.
NGC: Well, the formula we use is: f (tat, mach) = [(tat+273.16)/(1 + (0.2 * mach * mach))] - 273.16, but I'm sure Stu [Bowen] knows this, or probably much better ways; he knows way more than me about signal analysis etc. I think the problem they have involves a pressure line leak, which would throw off their static pressure and mach # calculations, which would throw off the SAT calculations in turn.
Sorry I can't offer more concrete analysis; we certainly have the raw
materials to better characterize the DADS data, but there is never the
time to spend on it. Hope all this helps, let me know if you need more,
see you soon!
NGC: GPS time is normally very accurate, but isn't the same as
UTC because GPS time is not adjusted for leap seconds (as UTC is), thus
leading to the 12-second difference today. GPS recievers usually apply
this correction automatically so that you get UTC (not GPS) time from them-
I usually call it "GPS UTC time"
to try and make it clear. FWIW, these errors were caused by operator
error, the operators in question being the flight techs. This being the
last mission and everything, and all of us being such nice people, we tried
to avoid pointing the finger of blame (which of course meant that most
people blamed the DADS, which as usual worked flawlessly. Sigh.)