LUXPAK data

[Brian Davis]

The LUXPAK team has already been putting data up on their journal
(wonderful!). I took a look at some of it and thought I'd throw some
other graphs up. I'm not sure what they shows, but there are some
suspicious aspects of them. I just put three graphs in the file
section, and I'll throw the Excel file I generated them from (LUXPAK-
BD.xls) up right after this.

LUXProfile: This shows the mission profile of the GPS elevation (in
meters!) as a function of MET (Mission Elapsed Time). Note that there
are a couple places on the graph that have got to be GPS drift errors
(I see at least three, the two obvious are marked).

LUXTemperatures: This is the external temperature as a function of
*elevation*, not MET. This way you can see a number of things. First,
the two temperature inversions are not at the same elevation (which
may not be a problem - after all, they were at a different location,
slightly (not much), and a different time of day. But I suspect these
things shouldn't shift the tropopause much, as the peak ozone heating
(that might be expected to increase as the day goes on) is generally
above that. I've over-labeled this graph with hints as to what I
*think* might be happening... but that depends on what calibrations
the LUXPAK group did (a heck of a lot, actually; read their site to
see what I'm talking about), and what post-mission tests they perform.
I do find it worrying that the "external" temperature shows a dual
value only when the tube heater is on - there's some influence going
on, but I don't know what.

LUXOzone: The ozone trajectory for the mission. This shows a
surprisingly similar trajectory to the external temperature, which
would make me *very* suspicious... except that there is a correlation
between the ozone concentration and the tropospheric temperature
inversion. I'm just not sure it should look like this - I've got to do
some more research. The fact that the ozone concentration at ground
level rises when the payload is sitting on the ground casts doubts on
what it's measuring... but the team *has* done calibration, and so I'm
not sure what's going on.

Oh well, more fuel for the fire of thought :)

--
Brian Davis

[Claude]

Thanks Brian,

I just want to put a couple of reflections:

1. LUXTemperatures : The PT100 sensor that we are using actually has a
rather slow response. The shift of the profile during the descension
could be a function of the time constant due to the much increased
descension speed -which didn't play the same role during the slow
ascension -. In other words, your plot temperature against altitude
could suffer from that, during descension showing the values measured
at a bit higher altitudes. Please consult http://www.convict.lu/htm/rob/hale3.htm

2. LUXOzone : That we are measuring concentrations that are decreasing
in that part of the stratosphere, where we should expect high ozone
activity (b.t.w. responsible for the temperature inversion) We suspect
that there must be some failure in the data processing inside the
ozone-sensor that we are using. So far we got no information from the
producer, how they calculate ozone-sensor concentrations from the
sensor-nose readings, and whether the results include air pressure/
density. We will have to check this with ECOSensors.

This keeps on intriguing us.

[Brian Davis]

On Aug 4, 3:56 am, Claude <claude.baum...@education.lu> wrote:

> The PT100 sensor that we are using actually has a rather slow
> response. The shift of the profile during the descension could be
> a function of the time constant due to the much increased

> descension speed - which didn't play the same role during the slow
> ascension.

True, and a very good point. Since you have a profile of the
temperature going up as well as down, you *might* be able to take that
into account, but it's going to be a tricky problem... especially
because during descent (turbulent and fast), boundary layer effects
will be much lower - the payload is coupled thermally to the
environment better during descent than ascent, but how much better is
hard to say. On top of that the time constant will be much longer at
high altitudes than at low altitudes - something like a factor of 50
times longer! Getting accurate high-speed temperature readings of air
that thin is not at all easy.

Unfortunately, my data can only be used to apply an upper bound to the
outside temperature. If the internal temperatures are going down, it
must be because the payload is still loosing heat, and therefore the
temperature outside is still lower. The minimum temperature
experienced by my payload was 254 K (-19 C) at an elevation of 8583 m
(just a little shy of the height of Mt Everest), so I know at that
elevation, the temperature was less than that.. although I don't know
how much less.

> Please consult http://www.convict.lu/htm/rob/hale3.htm

Hmm. You mention the following in the journal ("add-ons 08/08/03"):

"The inner temperatures first rise then fall to a minimum, then
rise
again. But the second hump FOLLOWS the one shown by the PT100
graph. Thus, no interior temperature rise may be the cause of the
PT100 rise."

I'm not sure that's true. The PT100 temperature will rise any time it
is receiving more heat than it is loosing. While it's true it's second
rise is later than the rise in the internal temperatures, that's not
what makes a difference for heat transfer: only the relative
temperatures matter. At a mission time of 1:45:00, the PT100
temperature starts making a significant swing up... but at that point,
every internal temperature is still well above the PT100 reported
temperature, so heat was still be conducted out of the payload and
into the sensor itself. If everything was close to equilibrium, then
when the internal temperatures trended down the heat conduction might
have trended down and *if* the PT100 was in thermal equilibrium with
the surroundings it might have begun to decrease in temperature. The
problem is nothing on these missions is in thermal equilibrium. It's
really complicating my analysis as well. For instance, the three
temperature sensors I have are exposed to heaters (who's output was
dropping, and not in a way I could measure), batteries (the heater
batteries actually put out a good bit of heat themselves, at least
early in the mission), and convective, conductive, and radiative
transfer within the payload. As the air pressure drops, not only does
radiative transfer begin to dominate, but boundary layer effects
become important (since the boundary layer depth is proportional to
the square root of the inverse density, as the density of the air
drops by roughly a factor of 50 the boundary layer becomes a factor of
7 thicker, really decreasing thermal exchange by convection, even
around the sensor head itself.

> This keeps on intriguing us.

The same on this side of the Atlantic :)

--
Brian Davis

[Brian Davis]

On Aug 4, 8:35 am, Brian Davis <brda...@iusb.edu> wrote:
>> You mention the following in the journal ("add-ons 08/08/03"):
>
>    "The inner temperatures first rise then fall to a minimum,
> then rise again. But the second hump FOLLOWS the
> one shown by the PT100 graph. Thus, no interior
> temperature rise may be the cause of the PT100 rise."
>
> I'm not sure that's true.

Having taken another look at the data and plotted up *all* the
temperatures on the same graph, I think I was dead wrong. It *does*
look like all the internal temperatures are being driven by the
outside temperatures and the heaters, not the other way around (the
PT100 being warmed by conduction from inside). The PT100's response is
sharp, while all the internal temperatures responses are much
"softer".

--
Brian Davis

[Claude]

Starts to become really puzzling. Hope we'll get comparable data soon.
Anyway, at this point I just would like to make sure that we will hand
out valuable data to the kids who will be doing much of the evaluation
in Francis Massen's math class in September. But the temperature data
and the ozone data are the most intriguing.

[Brian Davis]

On Aug 4, 2:46 pm, Claude <claude.baum...@education.lu> wrote:

> Starts to become really puzzling. Hope we'll get comparable data soon.

OK. *Now* I feel like an idiot.

Gypsy took detailed pressure measurements the whole way up, and the
pressure at any given point in the atmosphere depends only on the mass
above it. If the temperature and gravity are assumed to be constant,
you can calculate the pressure using a constant scale height.

Of course, the reverse is also true: given a pressure change, that
implies a certain scale height, *and thus a certain temperature*. Why
I didn't put those fact together quicker I have no idea, but as a
physicist it REALLY annoys me.

Anyway, take a look at the graph I just uploaded, "External
Temperatures.png". I took my data and used it to calculate a local
scale height based on the previous 30 seconds of data, and then used
that scale height and the theoretical value of "g" at that altitude to
deduce the external temperature. It has a nice slope of 5.82 K/km
below the tropopause, and a more gently slope of 3.22 K/km above it.
Minimum temperature was -62 C, while the bottom-most layer of the
atmosphere was around 18 C (I know the ground and payload temperatures
exceeded that easily, but this is the bulk atmosphere). I've not done
this with your data yet, but certainly could (OK, probably will). when
I plot the external temperature on the same graphs with Gypsy's
internal temperatures, I see they start warming up right about the
time on descent that the ambient atmosphere is warmer than the chilled
interior, just as expected.

> Anyway, at this point I just would like to make sure that we will hand
> out valuable data to the kids who will be doing much of the evaluation
> in Francis Massen's math class in September.

Absolutely. The above problem is actually a great one in atmospheric
science for a class, or a simple math problem (it involves the natural
log as well).

--
Brian "I should NOT have missed that for that long" Davis

[Eric]

I've uploaded 5 new image files:

1) Internal and external temperatures collected by Alyssa (the local
high school student). Her payload was flown, but not LEGO-related.
Shows some of the same interesting features as LUXPAK. Note, that when
we recovered the payload, the external temperature sensor had been
pushed back into the payload. We *think* this happened at landing, but
can't be sure.

2) The external temperature vs altitude for Alyssa's data (same note
as above about the external temperature sensor).
We are not sure about how fast the response of the sensor is. We use a
HOBO datalogger by Onset if you want to dig around.

3) Acceleration range (max/min) for the NXT controlled digital SLR
payload. Notice that it landed on it's side so is ends up reading
around 0.25 G's at the end (you can see the camera on it's side in the
photo gallery). The acceleration is for one-axis only (nominally
vertical) and was measured with a High-technique 3-axis accelerometer.
The altitude data is from the GPS logs already posted.

4) The internal temperature of the SLR camera payload. The heater was
set to go on at 10 C and off at 15 C. It looks like it turned on
around MET=45 mintues and stayed on until the end. A standard LEGO
(old RCX-style) temperature sensor was used. The heater was the same
as described online (two resistors and AAA battery pack).

5) a combined graph of the LEGO datalog.

Eric

[Claude]

So that's very interesting: we see the same profile with extrema at
the same moments, but with better values than LUXPAK's. Now we should
be able to determine more closely what exactly the PT100 sensor
measured being located in the payload's isolation material. Thanks
Alyssa and Eric.

The comparative view of the outside/inside temperatures is most
interesting. Seemingly the payload was not heated, and the inside
temperature follows the outside temperature with a certain visible
delay. Cool graph.

-Claude

[Eric]

Alyssa's payload was heated, but it was also very leaky. You can see
the slight upward trend before launch due to the heater. The hole for
the camera was fairly large and not sealed. The camera stopped taking
pictures after about 46 minutes (MET=95 minutes), just when it reached
the lowest temperature (-20C). At that temperature, there is basically
no hope of the camera functioning because the battery is frozen. She
had the standard AAA battery pack heater inside, but it was obviously
not enough (if she had kept it 10C warmer the camera probably would
have made it through the entire mission).

Eric

[Claude]

Thanks, all this helps a lot.

Just another question. Is some UV data already available?

[Davis, Brian L.]

> another question. Is some UV data already available?

I believe the only UV data was from the FLL90 team's payload, and David wanted to wait to have the kids actually deal with that (as part of the process).

--
Brian Davis

[Brian Davis]

On Aug 11, 1:54 pm, Eric <lego.profes...@gmail.com> wrote:

> Alyssa's payload was heated, but it was also very leaky... if

> she had kept it 10C warmer the camera probably would have
> made it through the entire mission).

Ouch. Well, speaking as someone who's camera paylaod failed *at
launch*... I more than sympathize :). In fact, I've gotten my payloads
back and still can't figure out what's going on in some cases.

On Alyssa's temperature measurements, what Onset logger was it, and
what external sensor? Most of the HOBO line lists as "90% in 6 min at
1 m/s airflow". If the payload was falling at 100 mph (45 m/s) it
would have potentially come to equilibrium 45 times as fast... except
that at altitude the actual density is around 1%, so that "45x greater
airflow" actually corresponds to mass flow of 45% of the normal they
seem to be listing, so equilibrium time to 90% would be on the order
of 10 minutes or so... and in 10 minutes, the payload has dropped to a
completely different layer of the atmosphere. It *is* noticable on her
data that the external temperature graph becomes more "smooth" during
the descent, which is interesting.

Q: How do we make a good (and of course semi-cheap) external
temperature sensor that has a short equilibrium time? There really
*should* be something based on the speed of sound, but I've not been
able to find anything as yet. Anyone?

Eric, when you get the chance could you throw up the actual
acceleration data? You sampled one axis (nominally vertical), while
Gypsy sampled the peak net acceleration. I'm curious how the two
datasets compare (i.e., if there was any point to my more complicated
method, or if it could be dispensed with for future missions).

--
Brian Davis

[David Levy]

Yes, that is correct. The team will be meeting this Sunday to extract
the data from the returned payload. I'll have them upload the raw
files to the HALE-TEAMS files repository along with some "first draft"
charts.

They will definitely need assistance and direction with graphing the UV
data in a useful form. Look out for team discussions on Sunday and next
week.

After that, the kids will be picking up again in early September when
the FLL Climate Change challenge is announced. Their first milestone
will be to prepare their payload to be exhibited at the Smithsonian Air
and Space museum on October 4 in Washington DC. The kids will then
continue to polish their presentation for the Virginia FLL Regional
tournament in mid November.

David

[Eric]

The HOBO is model U12-012. The temperature sensor is TMC1-HD.

I think the only way to get a fast response time is to go with a
thermocouple (low mass). I'm not very familiar with temperature
measurements, but folks around here seem to think that thermocouples
are the only way to go.

I'm uploading the Excel file of the LEGO accelerometer data now.
Remember, that I don't log the actual acceleration (not enough memory
for that). I sample at 10 Hz but only store the max and min seen
during each 30 second interval. Thus, I logged the "range" of
acceleration to a very high resolution, but not the actual
acceleration levels. To do that, I would have to log too slow to
capture any dynamic signal content (i.e. aliasing is a big problem)-
which makes the data nearly impossible to interpret. To get around
this problem, I sample fast but only log the extremes. I retrospect, I
should probably log the average too.

Eric