The barometric (static port) pressure looks very, very nice here.  Precise and self consistent - until you compare it with the expected value based on the GPS altitude.

(Note the x-axis is scaled in status-telemetry data points above, which are 4 seconds apart)

The barometric altitude given by the glider obviously diverges from the GPS altitude as you go up to high altitudes. 

The glider uses an algorithm to get altitude from barometric pressure that is based on the ICAO standard atmosphere model.  This algorithm was verified independently against government weather sonde data for the same day, and found to be correct.

But the baro pressure itself seemed to be in error by about 3% over its full scale of 110 kpasc.  This is simply a calibration error, which was corrected. (Note the x-axis above is scaled in seconds)

Battery voltage at the power board matches the expected trend.  Manual measurement of battery voltages before and after flight corroborate this data.

The down-spikes appear to be caused by the intermittent load of using the cameras, and longish jpeg downloads that use the data radio.  (Note the x-axis above is scaled in status-telemetry data points, which are 4 seconds apart)

The external temperature sensor output looks good, but seems to be self-consistent rather than accurate, if that makes sense. 

When compared to the ICAO standard atmosphere temperature for 43,000 feet, or government weathersonde temperatures from the same day and altitude, the Te looks to be about 15 degrees Celsius high for the higher altitudes.  In other words, it's measuring the fuselage skin temperature more than the external temperature. 

To try to fix this problem, a small metal fin was attached to the external temperature sensor for the next flight.  (Note the x-axis above is scaled in status-telemetry data points, which are 4 seconds apart)

Nice internal temperature data here, which is roughly corroborated by the temps given by the GPS, and the bus-board's temperature sensor (not shown).

The range is within the design tolerance,  and consistent.  This also shows the fuselage insulation is working significantly better than in ground test of its effectiveness - matching the design goal, in fact! (Note the x-axis above is scaled in status-telemetry data points, which are 4 seconds apart)

After release, the "expert system" level autopilot detected it was falling, and switched into trim-out mode immediately.  That mode has no other goal then to establish good trim and a steady ground track.

The data during the initial descent is good-quality, and shows the glider dove straight down, with some movement relative to the ground shown by the GPS.  That movement is consistent with the glider diving downwards with very little horizontal speed relative to the air, i.e., simply drifting downwind as it fell.  The GPS velocity data also shows it accelerated at about 1 g downwards, but shows very little horizontal acceleration. 

Yet, based on the pitot-airspeed data, which fits well with the ambient air pressure and descent speed at any given second, the wings failed at about the speed for 7g's load on the wings at normal pitch trim (assuming the trim was normal).  When the wings failed is obvious from the instant loss of GPS lock and pitot-based data.  Seven G's is about their maximum design loading, so this is a failure to control rather than a failure of the wings.  The airspeed at this point had built up to a level far too fast for the altitude.

The physical evidence from the wings - the bent-up left wing's joiner tube - also shows that the wings failed in a positive G overloading.  This appears to have been followed by a skewed snap roll to the right (due to losing the right wing?), which twisted the remaining left wing and caused the fin to fail to the left.

So at first glance, it seems the wings were lifting, which seems to say it wasn't a problem of too-low a pitch trim.  The telemetry also gives the rudder position the autopilot used at each of those critical seconds - and a human pilot, given the nav data available, could have done no better.  The autopilot did exactly what it was programmed to do at each point to trim the flight path straight.

There are two likely possibilities:

•   The glider was seriously out of trim in a rudder / roll, and was in a tight spiral, despite it demonstrating straight trim in manual control test drops.  Simulator testing did show the autopilot could not handle an initial out-of-trim condition that resulted in a roll-rate of more than 60 degrees per second.
    The high true airspeeds at that altitude would amplify such a problem.  It would not take much rudder-skew at all to cause this.  Despite low-temperature testing of the wings and fuselage to see if warping occurred, something might have been missed.
  
  
•   It's possible the wings actually failed not directly from a spiral-dive induced positive overloading, but due to flutter from the excessive airspeed.  Too-low a pitch trim could have been the major culprit here.  Overspeed - induced flutter could then have caused the fin to fail first, leading to a tumble that pitched the wings up and resulted in their positive-G-loading failure. 

Without second-by-second G-loading and roll-rate information, or a visual record, none of which are available, there is no way to tell the difference between these potential causes.  The only thing to do is try and attack all possible causes.

On the bright side, there is every indication that the performance of the airframe, software, and hardware all met or came very close to their individual design specs.  The problem, whatever it was, is most likely at the specification or high level design level, rather than a component failure.

• Aileron-based control with a fixed fin (no rudder) for more positive roll / turn control.

• Data from a Z-axis G sensor, and roll-rate from a rate-gyro, included in telemetry.

• Release as high as is possible next time while still able to obtain video of the release and recovery.

• Be more conservative about having the initial pitch trim for a lower flight speed.

• Use a better film camera, one with auto exposure control, and try to deal with the frost issues on the camera window that appeared to exist in the high altitude photos.

A small sensor board was constructed that senses up to +-16 G in the Z-axis, as well as a roll-rate using a ceramic/piezo gyro. So, it should be possible to get good roll-feedback control from a low-cost gyro, even if it isn't up to the quality that would be needed to do inertial-nav tricks.