JOURNAL  (III)    go to journal (I)  go to journal (II)  last update 2008/11/29

Main Mission links:

	H.A.L.E. site at Nevada University
	space photos
	H.A.L.E. forum
	live blog

1. Meanwhile there is some confusion about timing terminology and references. In the course of this page we started using the term "Mission Elapsed Time" (MET) as the LUXPAK system-time. Then Brian Davis computed the LUXPAK elevation data against MET in the Excel-file LUXPAK-BD.xls, where he identified MET with the start of Balloon#1. Now Eric Wang proposes a new document GPS summary.xls with MET* = 0.0 corresponds to 6:52:43 PST, the moment of launch of Balloon#2. (We denote MET* - MET_star - as Eric's mission time)
   1. If we are talking about MET on this page, we will refer to the start of Balloon#1 as Brian suggests: MET = MET* - 48,8667 [min]
   2. Since LUXPAK was switched on 157 seconds before the launch of the balloon, we define: LUXPAK_time = MET + 2,61667 [min]
2. In the announcements of the HALE project, Balloon#1 was supposed to transport LUXPAK. However this balloon was launched about 49 minutes after Balloon#2. Now in the recent official web-pages after flight, names have been inverted. Since the LUXPAK journal (III) was started early after the mission, we kept on using the old names. So, in the course of this page
   1.  Balloon#1 = "ENERGIZER"-Balloon = Balloon#2* , carrying LUXPAK  (the star indicating the new official name)
   2.  Balloon#2 = "NXT"-Balloon = Balloon#1* 

• The H.A.L.E. mission succeeded !!! Balloon #1 and  #2 lifted to 99560 ft and 99730 ft respectively. They landed more or less safely after about 2 hours flight. The ground team recovered the payloads except one - the LEGO Mindstorms team's top secret payload is missing. Otherwise : Congrates to the ground team !!!
• Here a couple of screen-shots of the HAM tracking. (Open the picture in a separate window to see the details). The red line shows the path of Balloon #2 and the green the one of Balloon # 1 carrying LUXPAK. The payloads were found back by additional GPS tracking systems.

• To complete this journal, we add a few pictures that we gratefully borrowed from the ground team:

Add-ons 08/08/11 :

• Just a few other photos that we borrowed from Eric:

• Yesterday evening Eric sent us the data file. There were some troubles during the upload from LUXPAK to the LabVIEW S_L_VIEWER.vi program. Since the upload process requires human manipulation on the PC and the RCX, some synchronization issues appeared that rapidly were solved. Finally Eric was able to extract all the data. Thanks !

• We now will go through the data and comment them:

1.  Balloon altitudes

• The second balloon was in fact "Balloon #1" that carried LUXPAK.

• From UNR we took the altitude graph in order to have a timing reference.

• Brian Davis plotted the data in a better way: (thanks Brian)

Add-ons 08/08/07 :

• Francis put together teh following graph, where he deduces the ascending and descending speed:

Add-ons 08/08/08 :

• We changed Brian Davis' table, where he relates the LUXPAK elevation to MET. In fact, LUXPAK has been switched on 157 seconds before MET. this has to be respected. Here the new relation: LUXPAK_time_elevation_CB.xls. This is important while comparing the atmospheric pressure data to the height for example.

Add-ons 08/08/11 :

• A 3D-profile of the balloon positions (credits to Eric Wang)

2.  Atmospheric pressure

• The UNR ground team was very careful with LUXPAK. Thanks ! They didn't close the styrofoam box in an air-proof way, which would have corrupted the pressure mesaurements.

• It now would be interesting to have a comparable pressure profile. Brian, could you share yours in excel-format?

• It seems that there is a certain drift, that is difficult to explain. Might be that the pressurization between the exterior and the interior has a very high time constant: compared to the altimeter measures there is a delay of about 5-10 minutes between the extrema.

• The minimum value is 12hPa. Brian indicates 14hPa.

Add-ons 08/08/03 :

• Brian Davis measures 882hPa at start of Balloon#2, which was launched about 1 hour before Balloon#1. LUXPAK measured 861hPa. Eric reported that it started raining, when Balloon#1 was launched. This might explain the difference.

• The final drift probably depends on the temperature increase of the container atmosphere.

• Altitude at start was 1428m. The landing ground was 1232m above main sea level. From the formula exposed at  http://www.atmosphere.mpg.de/enid/1442 we can calculate that the pressure at landing altitude 880hPa -assumed the atmosphere was constant. LUXPAK measured 882hPa.

Add-ons 08/08/06 :

• From the Balloon#1 GPS data and the pressure data, Francis realized the following graph (ignoring the values between the impact and the system stop at MET 3h07:

Add-ons 08/08/08 :

• The reason for the apparent hysteresis in the graph above (08/08/06) is that Francis used Brian Davis' elevation versus LUXPAK time, where he ignores the delays between LUXPAK time and MET.

Add-ons 08/08/09 :

• And with LUXPAK_time the "banana-type" shape of the graph disappears. With Statistica v.7.1. the best exponential fit is :

3.  Ozone concentration  leaves us puzzled ????

• The ozone-concentration peaks at Mission Elapsed Time (MET) 25' and 1h50' correspond to the altitude 40000ft = 12km, reached during ascension and 5km at descension. Interestingly Fig. 5 of the  document on the sensor-equipment and the calibrations shows this troposhperic peak. But the stratospheric most significative peak is totally missing at altitudes 20-30km. This is intriguing. Francis, I've no cue. Ah, I noticed that we have a maximum of balloon speed over ground -equivalent to the wind velocity- at 12km altitude.

• The slow recovery after the mission perhaps is related to the temperature of the air that arrived at the sensor nose. In fact there has been a big issue with the heater that we will analyse now.

Add-ons 08/08/03 :

• I wonder, if we must not take into account the air density. Francis, perhaps we must contact the sensor producer to hear more about how the sensor actually measures the concentration, and what formula they internally apply.

• Brian plotted the data against elevation: (thanks Brian)

Add-ons 08/08/04 :

• Important observation: we completely forgot about the clouds !!! Above 12km there are no clouds anymore. Does this affect the readings?

LUXPAK ozone concentration excel file

A few links to to stratosphere ozone measurments: (not sure how useful they are)

	http://www.rsc.org/delivery/_ArticleLinking/DisplayHTMLArticleforfree.cfm?JournalCode=EM&Year=2005&ManuscriptID=b412184h&Iss=2
	http://www.ozonelayer.noaa.gov/action/ozonesonde.htm
	http://www.atmosp.physics.utoronto.ca/SPARC/SPARCReport1/2.05_O3sonde/2.05_O3sonde.html
	http://www.ccpo.odu.edu/SEES/ozone/class/Chap_3/3_2.htm
	http://www.fz-juelich.de/icg/icg-2/wccos/
	http://www.physics.umt.edu/borealis/Ozone%20Lab%20Report_06.pdf

4.  PWM_heater

• The heater switched on at 50% duty cycle during the first 10 minutes as programmed.

• Because the air temperature inside of the ozone-sensor case never dropped below 10.5°C, the tube heater was not switched on. At Mission Elapsed Time (MET) 1h45' however, the battery-temperature dropped below 25°C, switching on the heater at variable power according to the function described in Fig. 11 of LUXPAK_control.pdf.

• After 2 hours, the heater should have switched off. But due to a bad bug in the RCX firmware, the heater task was stopped BEFORE switching off the RCX outputs. So, the heater was no longer controlled and continued powering during 1 hour, before the ground team switched LUXPAK off. In the program-part below, which is executed in the heater_task itself, the task is stopped, so it cannot reach the stopping of the outputs anymore. The reason for this bug is:

  • we had moved this code from another task to the heater task, without thinking about the issue that, if a task stops itself, the following code isn't executed anymore.

  • the final firmware never was tested over that time.

  • hmm. We need to learn the lesson that any firmware change requires new tests.

• This bug could have led to fatal troubles, because no other task controlled the heater. Fortunately the PWM value was 36% only. And there also were the hardware fuses that would have cut the current.

Add-ons 08/08/04 :

• The explanation why this bug is in the firmware is a whole story. (Everything has a cause !) The small code portion above in fact was part of another task that was supposed to react on time. The idea was, that once the system time passed 2 hours, that particular task should first stop the heater task in order to prevent it from restarting the heaters because of sensor triggering. Then the timing task should switch off the heaters. But, when finishing the firmware, we moved the code portion into the heater task, because we wanted to gather everything concerning the heaters in one task. We totally forgot that this code move required that the heaters should first be stopped and then the task.... So, once again, it must be said: "Never change a running system!"

5.  Battery temperature

• The battery temperature rises during the first heater time. During the ascension the temperature at the battery pack doesn't change very much. But during the descension, temperature drops rapidly below 25°C, triggering the heater. As explained, the heater sould have shut down after 2 hours. But, it didn't. Thus, the battery temperature increases, while LUXPAK is waiting for the ground team.

6.  RCX temperature

• The RCX temperature reacts similarly to the battery temperature. The RCX reacts more quickly and its inner life is better protected from the LUXPAK inner atmosphere. Therefore the temperature doesn't drop so much.

7.  ozone sensor temperature

• The ozone sensor temperature changes earlier than the other parts. At least the first well happens about 10 minutes before the battery temperature minimum. The reason for this is obvious:

  • The ground team closed the upper space between the main body and the cover, but the lower was kept open. During the ascension the cold air reached the sensor nose through the tube passing through the heater. During the descension however the cold air came in from the small stud. The box interior was filled from the un protected space between the box body and the cover. This explains the rapid changes.

Add-ons 08/08/04 :

• This sensor is placed inside of the ozone sensor box. It is in direct contact with the air that streams in from the tube. 

8.  tube temperature

• The tube temperature obviously rapidly increases during the first 10 minutes, then slowly drops. Interestingly, it stabilizes around 23°C until the final phase, where the heater is activated and, due to the firmware bug, is not stopped.

9.  air temperature  leaves us puzzled ????

• The interesting air temperature profile is not what we expected. It is minimal at MET 40' and 1h45', during ascension corresponding with the altitude 60000ft ~= 18km. (Because the descension is so much faster than the ascension, the sensor may perhaps react with a certain delay due to its own thermic inertia.However there is a clear temperature inversion starting from 18km altitude. The stratospheric inversion also is visible on the path that the balloon took. In fact it zigzagged at the indicated altitude. The speed over ground was very low compared to the speed at lower altitudes (see above):

• This profile must be compared to other participant's data !!!

• The final temperature of about 45°C shows how hot it was in the landing area around noon.

Add-ons 08/08/02 :

• The absolute values of the PT100 values may be a bit too high. Perhaps one reason is that most of the sensor's 2cm metallic collector sticks in the styrofoam container wall. (See Fig. 1 of the document on the sensor-equipment and the calibrations) Only 3-4mm are in direct contact with the outer atmosphere. Probably the outside temperature is 5-15° colder than indicated on the graph. Francis, we have to model out, what we actually measured in the isolation material.

Add-ons 08/08/03 :

• Important observations:

  • The tube-heaters were off during most of the flight. They operated only during the first and the last 10 minutes. The final heating was due to the firmware bug as explained.

  • 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.

  • If we have a look at one of the 1976 standard atmosphere graph, we can observe the temperature inversion in the stratosphere (...OK, I took it from wikipedia, referred from the German page about the standard atmosphere... Francis, we need to find more about this topic.). So, PT100 profile might well be correct.

• From http://www.atmosphere.mpg.de/enid/1442 we borrowed the following interesting graph that perhaps helps us understand what's happening, although the temperature increase on this graph is far more weak than ours:

• Brian Davis exposes another theory of the temperature profile: (thanks Brian)

Add-ons 08/08/04 :

• Brian has been hit by the same puzzling virus: trying to find out what the PT100 actually measured.

• He argues in the discussion group, self-reflections omitted :)

  • 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" (see below). 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.
    

Add-ons 08/08/11 :

• The non-LEGO payload designed by Alyssa produced the following temperature profile:

• The profile corresponds to the one measured by LUXPAK, although the temperatures are much deeper.

• Brian Davis' theory that the PT100 sensor is not cooled by the convection in the atmosphere because of the extreme low air-density still seems appropriate. If we correct the PT100 data in linear combination with the pressure, then the values measured by Alyssa's payload may easily be reconstructed as shown on the next picture.

  • Notes:

    • we use an apprximation of Alyssa's data, because the values are not available.

    • we only consider the relevant time of Alyssa's data

    • the rectification does not affect LUXPAK's increase at the end, which is due to the heater bug.

Add-ons 08/11/29 :

• Merging all the temperatures in one graph, we can see that the internal temperatures were relatively constant during the mission and only drifted away due to the programming bug:

LUXPAK air temperature excel file

some links: (don't know how useful they are):

	http://www.atmos.washington.edu/2005Q4/212/Lecture6Notes.pdf
	http://farside.ph.utexas.edu/teaching/sm1/lectures/node56.html
	http://www-paoc.mit.edu/labweb/notes/chap3.pdf

10.  back scattered light intensity

• The back scattered light intensity slowly grows during ascension, At MET 1h25' the almost freefall starts and there are many small variations. Why the values grow afterwards, peak at MET 1h50' is difficult to explain.

• After the impact, some kind of oscillations start, which certainly are related to clouds in the sky.

Add-ons 08/08/04 :

• The local maximum at MET 25' perhaps is due to the fact that LUXPAK has reached the altitude above the clouds.

Add-ons 08/11/29 :

• Francis has worked a lot in order to find conclusions from the backscattered light data, especially to determine the albedo. Using a special simulation program called "SMARTS2", he was able to determine the local solar irradiance. This was necessary, because we have not been able to get valuable data from the launch area.

• The results are impressive. First the ground albedo could be yielded to 0.16 and 0.14 respectively. Second the albedo just over the clouds was calculated to 0.61, which is very realistic, if we consider that there were many stratocumuli clouds located between 2000 and 7000m.

11.  RCX supply voltage

• The supply voltage drops by 1V during the first 10 minutes heater time. However, due to a slight increase of the battery temperature, the voltage grows proportionnally.

• During the non heated time. The voltage slowly drops by 0.2V, with a stabilzation at MET 1h00 (battery temperature local minimum).

• After MET 1h45' the voltage drops once again, but then slowly grows due to the temperature increase in the batteries.

12.  system time

• This graph proves that the datalogging process worked without failure, since the system time is also logged. If ever there appeared discontinuities, some data loss would have happened.

Add-ons 08/08/08 :

• From the system-time we can deduce that very few data records have been lost for any reason:

  • 25 lost records of 1390 = 1.8%

  • Note that there have been 1365 valid records. Missing records were detected, because the system-time incremented by 16 or 17 seconds instead of 8 or 9.

• LUXPAK arrived back home safely. Note the balloon fragments and the battery sets that Eric added to the packet. Thanks ! LUXPAK looks as if it never went off. No scratches or damages what so ever. We hardly can believe it did that trip!

• We have had a presentation of the HALE project yesterday with a very interested audience.

French announcement:

Le Konvikt et le Lycée Classique de Diekirch participaient au concours H.A.L.E lancé en avril 2008 par l’Université de Nevada-Reno pour développer un module de mesures scientifiques ; ce module devrait être emmené par un ballon jusque vers la stratosphère (env. 30 km). Seulement 7 équipes par le monde furent acceptées, dont celle du Konvikt/LCD avec son projet LUXPAK. L’entreprise fut lancée pour commémorer le 10ème anniversaire du développement robotique Mindstorm/RCX de Lego, et LUXPAK utilise à plein les capacités du microordinateur RCX. Claude Baumann et Francis Massen présentent cette aventure qu’ils ont réalisée avec leurs étudiants et qui s’est terminée avec le lancement et la récupération réussies de LUXPAK dans le désert du Nevada.