Data downloaded via parachute from a NASA super-pressure balloon

In April to May 2023, the superBIT telescope was lifted to the Earth's stratosphere by a helium-filled super-pressure balloon, to acquire astronomical imaging from above (99.5% of) the Earth's atmosphere. It was launched from New Zealand then, for 40 days, circumnavigated the globe five times at a latitude 40 to 50 degrees South. Attached to the telescope were four 'DRS' (Data Recovery System) capsules containing 5 TB solid state data storage, plus a GNSS receiver, Iridium transmitter, and parachute. Data from the telescope were copied to these, and two were dropped over Argentina. They drifted 61 km horizontally while they descended 32 km, but we predicted their descent vectors within 2.4 km: in this location, the discrepancy appears irreducible below 2 km because of high speed, gusty winds and local topography. The capsules then reported their own locations to within a few metres. We recovered the capsules and successfully retrieved all of superBIT's data - despite the telescope itself being later destroyed on landing.


Introduction
The Superpressure Balloon-borne Imaging Telescope [SUPERBIT; 1,2] was raised to ∼33 km altitude by NASA's 18.8 million cubic foot super-pressure balloon 728NT 1 .It was launched on 16 April 2023 from Wānaka, New Zealand, was carried East by seasonal polar vortex winds [3], circumnavigated the Earth ∼5.5 times, then landed in Argentina on 25 May 2023.During this flight, the telescope acquired deep optical and near-UV imaging of galaxy clusters and other astronomical objects [4][5][6].Early in the mission, data were transmitted to ground stations via Starlink and TDRSS satellite communications links.However, the Starlink connection was lost on 1 May 2023, and TDRSS became unstable on 24 May 2023.The root cause for each failure remains under investigation.All of the data were stored on board, as well as on redundant sets of solid state drives within drop packages.Several copies of the full data set were released via parachute prior to termination of the flight, and were safely recovered.The SUPERBIT payload was entirely destroyed on landing, and although in this case the data were eventually recovered from the remains of the on board drives, the use of parachutes to ensure the safe recovery of the data proved invaluable.
Four Data Recovery System (DRS) capsules were attached to the telescope before launch.As well as a parachute, each included 5 TB solid state data storage, a Global Navigation Satellite System (GNSS) receiver so it could work out its location, and an Iridium Short-Burst Data (SBD) transceiver, so it could report its location to the recovery team [and receive commands to, e.g., turn on or off a beeper 7].Two DRSs were released, and both were successfully recovered, with data intact.
In this article, we describe upgrades (since the first test of a DRS during a SUPERBIT engineering flight in 2019) to their release mechanism, communications with the telescope, and thermal control.We describe the performance of that hardware during operations, and also the performance of software that we use to predict their decent trajectory.Accurate predictions of the descent vector are essential to chose a safe landing zone.Neither the trajectory of the main telescope payload nor the parachute are actively controlled, but the timing of the release can be chosen so that the DRS lands in an area that is unpopulated for safety, but near a road to facilitate recovery.
Our hardware design2 and software 3 are both open source.Their success inspired NASA's 'FLOATing DRAGON' Balloon Challenge 4 .Following this programme, a similar capability to download data or small physical samples will be made available by NASA to all future super-pressure balloon teams, to insure against loss of communications, loss of payload, or destruction of payload on landing.Our experience suggests that teams should take up the offer.

Upgraded hardware design
The DRS capsules are based around a Raspberry Pi 3B attached to a custom 300 mm × 125 mm printed circuit board (PCB; see figure 1).They are powered by switchable 24V DC from the main payload while they are attached, then by two internal 9V lithium batteries after release.These batteries are the only components of the DRS that could be considered potentially hazardous, however, they are compliant with safety test criteria T1-T8 defined in section 38.3 of [8].They use a geared pincer mechanism to hold on to a loop of nylon cable tie underneath the main payload.After coordination with local Air Traffic Control, we issue a sequence of three commands (to prevent errors and fault propagation) that use a servo inside the DRS to open the pincer, allowing the DRS to drop away.
Each DRS is enclosed by a 3D-printed CPE hard plastic case and a closed-cell foam shell (see figure 2).One case was printed in PLA, which also worked fine but is harder to work because it is brittle.The foam shell absorbs impacts and adds a degree of waterproofing that proved useful when one DRS landed in snow.It is manufactured by pouring liquid PU expanding foam mix into a pill-shaped mould a few millimetres less than 6" in diameter, lined with a chicken roasting bag to create a waterproof outer surface on which contact details can be written [9].The total mass including parachute is 1.28 kg.

Alignment and attachment to the main payload
To prevent the DRS swinging while it hangs under the payload, during the 2019 test flight, it was sheathed inside a section of 6" plastic drainpipe.This worked flawlessly at altitude, when two DRS capsules were successfully released.However, during subsequent testing in a thermal vacuum chamber, the foam sometimes expanded and became wedged inside the pipe -to drop only when surrounding air pressure increased.To mitigate the risk of a DRS becoming wedged at altitude, we remove the pipe, and attach a 3D-printed PETG 'crown' to the top of the DRS (see figure 2).This fits into an inverted crown that is fixed to the main gondola.The crowns are kept together and the DRS held secure by pulling the cable tie taught.
A second pincer mechanism holds a 4 foot parachute, folded inside a spacer above the DRS.This size parachute yields a terminal velocity ∼4 m s −1 .This is fast enough to reduce downrange travel distance (hence uncertainty in predicted landing spot, which allows us   to avoid populated areas), while keeping kinetic energy comfortably below a 15 J safety requirement not to cause serious injury or damage.

Hardwired Ethernet to the main payload
It is possible for the DRS to communicate with the main payload via the Raspberry Pi's built-in WiFi.This worked successfully throughout the 2019 test flight -however, the launch of that flight was delayed because of radio interference.After much investigation, it turned out that the interference had nothing to do with WiFi, but it took time to rule out that possibility and to then look for the real source.To militate against future risk of delays, and to enable operation on payloads that require radio silence for scientific measurements [e.g.SPIDER; 10], we use hardwired Ethernet for the 2023 science flight.Inside the DRS, this involves a standard Ethernet cable plugged into the Pi's Ethernet socket.Outside the DRS, two twisted cable pairs were routed to a switch on SUPERBIT, which acted as a DNS server.
The six wires (four for Ethernet and two for power) join at zero-extraction force connectors 5 that separate easily when the DRS is released.2-pin versions of these connectors worked well during the test flight, but we found that versions with more pins did not sit well, and occasionally became disconnected during testing.We therefore used grub screws to fix half of the solid connector inside the crown, and half in the gondola mount, so they would be held together until release.

Thermal management
During the 2019 engineering flight, each DRS worked for only ∼15 minutes at a time, before overheating and shutting down until it naturally cooled.Subsequent testing in a room temperature lab showed two main hot spots (see figure 3).Assuming thermal emissivity coefficient e = 0.95, the main CPU reaches 42.5 • C while executing a simple Python script (the Raspberry Pi itself was reporting a CPU temperature of 49.4 • C), and the USB sockets reach 48.9 • C when a 5 GB file is written to an SD card in a small SD card reader.
Achieving robust operation during the 2023 science flight required mitigations for both.
To cool the main CPU, we mill a 53 gram aluminium heat sink/radiator that sits between the Raspberry Pi and the PCB.It is held against the CPU by a spring glued to the PCB, and contact is ensured with thermal paste.The aluminium block extends through a 56 mm×14 mm hole in the plastic case, ending flush with that, and is covered with Mylar tape to increase its infrared emissivity.Heat is radiated to space through a hole in the foam shell that was cut by hand (using an indentation in the mould to align it).The ambient temperature in the stratosphere is −40 • C [11].For what it is worth, we also stick a thin, off-the-shelf copper radiator to the RAM chip on the back.
To reduce heat production at the USB sockets, we use two 6" USB extension cables to relocate two SD card readers (they end up sitting roughly behind the microcontroller).
We also operate each DRS on a 5 minute on-20 minute off rota: powering up each in turn, copying data, then powering down.During a typical cycle during the night (day), the CPU temperature increases by 3.0 ± 0.3 • C (3.7 ± 1.0 • C) in 5 minutes (see figure 4).On one occasion during night 13, DRS1 was powered for two cycles, and its temperature rose 14.Before launch, four DRS capsules were mounted underneath the rest of the payload (see figure 5).They are oriented with their radiators towards the front of the telescope (which is never allowed to point towards the Sun) and enclosed by a loose skirt of Mylar, the inside of which is aluminised except for a ∼45 • pleat near the radiator.On two sides, an additional sunshield of foam wrapped in aluminised Mylar also protects the DRSs from incidental knocks.DRS1 was at the back left, DRS2 at the back right, DRS3 at the front right, DRS5 at the front left (DRS4 was our flight spare).Power and Ethernet cables are routed from each DRS up to SUPERBIT.

Data storage
Each DRS is fitted with 5 × 1 TB MicroSDXC cards: one in the internal slot that includes the Operating System, and four in USB card readers.We set these up as independent drives (rather than RAID, to further reduce thermal load), and copy data to one of the SD cards at a time, beginning with those mounted in a USB socket.An rsync script was not sufficient, because the SD cards were independent.Instead, whenever the Pi boots, a custom script compares files on the payload with those on the DRS (matching name and size, because some files such as instrument timestreams continually grow), and copies new data to an SD card with sufficient space.SUPERBIT's rate of data acquisition is sufficiently slow that we could have duplicated all the data to second SD cards on every DRS -but with so many backups already, we chose not to.
We tested MicroSDXC cards from several manufacturers before the flight.Resilience is more important than speed in this context, and we found considerable variation in cards' ability to withstand a harsh environment.SanDisk Ultra (A1 UHS-I Class 10 U1) and SanDisk Extreme (A2 UHS-I Class 10 U3 V30) cards worked reliably throughout our tests and the flight.Two different Integral (A2 UHS-I Class 10 U3 V30) cards showed an intermittent fault during testing: when used to house the Operating System, the Pi would occasionally require power cycling to boot.After a few early problems, this was not reproducible, so we flew two DRSs with SanDisk Ultra SD cards and two with Integral SD cards.All our Lexar (LMSPLAY001T-BNNAG) cards all failed during testing, so these were discarded.

One failure on launch
One DRS onboard SUPERBIT stopped responding immediately after launch.It is now impossible to determine why, but we suspect that the zero-extraction force connection became misaligned by the launch shock.It was one of the capsules using an Integral SD card, which may have also caused problems, but we power cycled it many times without response.All three other DRS capsules worked reliably for the entire flight or until they were released.

Descent and recovery
We initially intended to release one DRS capsule around mission days 40, 60, 80, and 100, whenever SUPERBIT passed over land, to mitigate the risk of the payload and all its on-board data being lost at sea.SUPERBIT did indeed pass over Chile and Argentina on mission day 40 (25 May 2023).However, in the early hours of the morning it became apparent that the main payload would need to descend later that day, because of reduced communications bandwidth, and a weather forecast indicating a Southerly trajectory away from further land crossings.After finishing the night's observing, and coordinating with local Air Traffic Control, we released (not one but) two DRS capsules over Santa Cruz province, Argentina.This strategy ensured that independent, redundant sets of data would be available both onboard and separated from the main payload.

Release time and location
We attempted to release two DRS capsules nearly simultaneously -so they would land close to each other, to simplify recovery.Low-latency communications with the payload had been lost, so we were forced to send release commands via Iridium SBD.We transmitted the two commands on independent channels.However, commands are queued and arrive after an unpredictable delay.
Contemporaneous logs recorded on SUPERBIT show that release commands were received at 12:30:58 and 12:31:25 UT.Taking into account an intentional 30 seconds delay for the Pi to shut down gracefully, we infer that DRS2 and DRS1 were released at 12:31:28 and 12:31:55 UT respectively.
The super-pressure balloon (SPB) host logged GNSS locations approximately once per minute.We interpolate between these to infer the location of SUPERBIT at the moments when DRS capsules were released (see table 1).During the 27 seconds between release events, SUPERBIT travelled 1.79 km on heading 101

Predicted descent trajectories
We predict the DRS descent trajectories and landing sites with PyBalloon software [9] that integrates a path followed by a test particle through winds described by Global Forecast System (GFS) weather models.When we did this live, we predicted descent vectors ∼61.3 km on heading 107 • , and a flight time of ∼32 minutes.However, the fast ground speed and high-latency communications meant that our uncertainty in the landing site was dominated by the unpredictable timing of release (2 minutes' uncertainty extended our error ellipses by 8 km).We therefore aimed for a large region of open, uninhabited land west of main road 12.These specific circumstances are unusual and unlikely to be repeated.Knowing with hindsight the precise times of release, we predict landing sites for DRS1 at −47.8594 • , −69.6307 • (altitude 878 m), and DRS2 at −47.8557 • , −69.6559 • (altitude 920 m), with 68% confidence limits of σ ∥ = 2.1 km in the main direction of motion, and σ ⊥ = 1.9 km perpendicular to that.With even more hindsight, we are able to interpolate between GFS model wind speeds issued before and after the DRS release.These lengthen the model descent vectors by ∼1.1 km, to predicted landing sites for DRS1 at −47.8655 • , −69.6153 (altitude 863 m) and DRS2 at −47.8600 • , −69.6444 • (altitude 850 m), with 68% confidence limits σ ∥ = 2.3 km and σ ⊥ = 1.9 km (see figure 6).Even in the absence of any additional information, the open terrain would have made it possible (albeit time consuming) to search for bright orange parachutes in an area this size.

Reported landing sites
Unfortunately, neither DRS reported or recorded its location during descent, as they are supposed to (and as they did during the 2019 test flight).It is therefore impossible to reconstruct their true trajectories.DRS1 spontaneously started reporting back at 14:13:46 UT, after having reached the ground, and DRS2 started reporting back at 14:31:15 UT (intermittently at first, and intermittently again overnight).Both DRS capsules reported line of sight to many GNSS satellites.However, their initial reports included measurements of low battery voltages, and we later found that DRS2 was lying in a patch of snow.We infer that, although the temperature of the Raspberry Pis was successfully managed in space for 40 days (see section 2.3), the adjacent batteries, which are used only after release, got very cold.We have previously used them in the stratosphere, but not for such extended periods.
Self-reported GNSS coordinates after landing placed DRS1 at −47.88167 • , −69.59300 • (altitude 786 m) and DRS2 at −47.86368 • , −69.67452 • (altitude 806 m), after averaging over several readings to provide ∼2 m precision.These are 66.5 km and 58.3 km horizontally from their release points, 3.8 km and 1.6 km from the pre-release predicted locations, or 2.4 km and 2.3 km from our best-estimate calculations that include weather data available afterwards.The true trajectories appear to have deviated approximately 950 m sideways from the predictions, with one landing 2.2 km earlier than expected, and the other travelling 2.1 km farther: both within predicted precision.
Our model for both the descent vector and its uncertainty thus appear accurate.The absolute uncertainty on our predictions is larger than previous drops because the high wind speed meant that capsules travelled farther downrange.Indeed, we have to extrapolate uncertainties from most of the test-drops used to calibrate our model [9].But even in this regime, compared to our predicted landing sites, three of the four coordinate offsets are inside the predicted 68% confidence interval, with one just outside.Compared to our bestguess landing sites, all four offsets are just inside.Furthermore, the two near-simultaneous trajectories neatly illustrate the irreducible component of uncertainty caused by small-scale spatial and temporal variations in wind velocity (gusts) -as well as local topography, when the predicted trajectory at low altitude is only 21 • below the horizontal.The two capsules started only 1.8 km (and 27 seconds) apart, but ended up separated by 6.4 km.

Successful recovery
Both DRS capsules were found at their reported locations in rolling hills (see figure 7), by the Search and Rescue team for the Governor's Office of Santa Cruz Province.The bright orange parachutes were visible from a distance and the beeping was audible.DRS1 was found exactly at its reported location, a few hundred metres from a track, and ∼24 km from main road 12. DRS2 was found a few metres from its reported location, with evidence of cougar prints in the snow.We surmise that foam and parachute nylon are intriguing but not tasty.
We recovered identical copies of all the data from both released DRS capsules -and also later from the unreleased DRS and the main data store on SUPERBIT (which also have slightly more telemetry data).However, SUPERBIT had been completely destroyed on landing, when its parachute failed to detach (perhaps due to similar thermal issues as the DRS capsules: analysis is ongoing) and it was dragged for 3 km through similar terrain, leaving a trail of debris.It is therefore remarkable luck that SUPERBIT's solid state hard drive was later discovered intact.We did not need it, because data had already been retrieved from the released DRS capsules, but having the original copy enabled us to verify that no data on the SD cards were corrupted.

Results
The DRS system comprises both hardware and software.Hardware worked reliably throughout the mission, in three of the four capsules.They were power cycled every 15 minutes for 40 days, and booted successfully every time.Data were gradually copied to every DRS as they were acquired, and later (after a mean delay of 20 days at altitude plus two days exposed in Argentina) recovered with no bit errors in 219 GB of files.Curiously, one of the 5920 files accumulated 10 bit errors when being copied from the telescope's camera data store to the central data store -but none were further corrupted, on either the central data store or the DRS capsules.
The internal batteries in the DRS capsules got very cold at altitude, and provided insufficient voltage to power the Iridium transceiver until they warmed up after landing.This meant the true descent trajectories were not recorded -which would have been interesting to compare to our model trajectories.However, the batteries did warm up, and worked successfully even from a exposed, high altitude location on Earth, while covered in snow.The capsules reported their location and were found.
One of the four DRS capsules failed to respond after launch.Following the destruction of the telescope to which it remained attached, it is impossible to determine the cause.We speculate that a cable or connector may have been dislodged by the launch shock, but we also note that the DRS in question used a brand of SD card that had displayed erratic behaviour during testing.Either way, only 75% hardware reliability calls for additional testing before future use, to reduce or improve single points of failure.
The software we developed to predict the trajectory of a DRS descending through the Earth's atmosphere worked very well, with accurate predictions and estimates of uncertainty.This is essential to drop the DRS to a safe but accessible landing site.It would also work as backup information to find a DRS that failed to respond after release (although the reliability of our hardware other than during launch meant that this was not needed).
Analysis of the astronomical data collected by SUPERBIT and the DRS capsules will be presented in forthcoming papers.

Discussion
The first use of the DRS capsules during a live science mission was a huge success.For a relatively small cost, we insured the scientific returns of SUPERBIT against a loss event that came true: high bandwidth communication links failed, then the telescope was destroyed upon landing.We recommend that future balloon missions consider using this or similar systems.Our hardware design and software are open source and freely available.Further development is continuing at NASA, with plans to offer a facility-class DRS system.
Possible improvements to DRS hardware include (a better way to secure) a low-friction connector so it does not become disconnected during launch.The jerk when a DRS falls away is sufficient that the right amount of rigidity might be provided by a standard Ethernet socket and plug with the retaining lug removed.Power Over Ethernet could remove the need for any separate power cables.A related aspect of this is that securing a DRS to the gondola mount currently requires fiddly routing of cables and cable ties inside a cramped case and pulling the ties taut (see figure 2).More convenient assembly/disassembly would make it easier to perform many more test drops in situ than we achieved.
Thermal management has greatly improved since our test flight in 2019 [9], with the Raspberry Pi operating reliably on demand throughout the mission.The internal batteries got cold, and a (throttled) thermal link from the Pi would help them stay ready to work immediately after release.Although our batteries eventually warmed up and worked fine after 40 days cold, we have not tested whether they would also recover as quickly after 100 days cold.It would also have been interesting if the DRS stored GNSS data (at high frequency) during descent, even though it was too cold to power the Iridium transmitter, so the trajectory could be compared to our prediction.This is not possible in the current design concept, which intentionally has only a low-power microcontroller chip and no flash memory available after release -to maximise battery life in case searching for the DRS takes a long time.

Figure 1 .
Figure 1.The DRS is based around this custom PCB with a Raspberry Pi in the middle.An Ethernet cable is plugged into the bottom right of the Pi, and attaches to a zero-extraction force connector at the top right corner of the PCB.Two SD card readers are plugged directly into the Pi, and two are attached to USB extension cables to reduce heat production at the sockets.Servo-operated pincer mechanisms can be seen on the right, with the pincer on the front holding on to the main gondola, and the release at the back holding the parachute.

Figure 2 .
Figure 2.The DRS capsules hang underneath the payload (here down is shown to the left).They are prevented from swinging or rotating by a 3D printed 'alignment crown' fixed to their top -which fits inside a mount on the gondola that has the inverted shape.

Figure 3 .
Figure 3. Thermal imaging of the top and bottom of a Raspberry Pi, during testing in a room temperature laboratory.Thermal emission is interpreted as temperature (red, white, green numbers) assuming emissivity e = 0.95.(a) The main CPU is the hottest component while executing a simple Python script.Nothing is attached to the USB sockets in this image.(b) The underside of a Pi attached to a DRS, oriented as in figure 1.The heat sink and SD card containing the Operating System are now cold at the top, but the USB sockets become hot during file transfer to SD cards in small readers mounted in the USB sockets.

Figure 4 .
Figure 4. Self-reported CPU temperature of the Raspberry Pi on each DRS during the SUPERBIT mission, for DRS1 (red), DRS2 (blue), and DRS5 (green).Temperature principally varies with the 45 diurnal cycles in 40 days (SUPERBIT crossed the international date line 5 times), the length and extent of which varied with SUPERBIT's speed and latitude.The histogram on the right splits times by positive or negative Solar elevation.Insets show temperature variations with increased temporal resolution -including, for illustration, the one occasion when DRS1 was left powered on for 30 minutes.Temperature measurements were only available when a DRS was powered on, and horizontal lines merely show the last reported temperature.

Figure 5 .
Figure 5. (a) Close-up of a DRS in flight configuration.The closed-cell foam shell surrounding the DRS can be seen poking out below a skirt of aluminised Mylar.It is further protected on two sides by sheets of foam insulation also covered by aluminised Mylar.Cables are routed upwards, on the mounting frame.(b) SUPERBIT suspended on the launch crane.Four DRS capsules can be seen at the bottom, each attached to a corner of the frame holding the solar panels.The blue and white object hanging between them is a ballast hopper.Throughout its mission, the telescope keeps its back (on the right in these photos) oriented towards the Sun.

Figure 6 .
Figure 6.Descent trajectories of DRS1 (yellow) and DRS2 (red) capsules, which were released over southern Argentina on 25 May 2023.Pins mark the known release and landing positions; everything else is modelled using the pyBalloon software [9].(a) View from altitude, looking North.Predicted descent trajectories, spanning 62 km horizontally and 32 km vertically are shown, with vertical lines every 15 seconds for the first minute, then every 1 minute.(b) Location of trajectory within Argentina.(c) Zoomed-in map view, comparing the true landing sites to the predicted 1σ, 2σ and 3σ uncertainty ellipses.The background image was created with Google Earth, using data from SIO, NOAA, U.S. Navy, NGA, GEBCO and imagery from Landsat/Copernicus.

Figure 7 .
Figure 7. Landing sites of the DRS capsules in Argentina.(a) General terrain and the Search and Rescue team from the Governor's Office of Santa Cruz Province.The bright orange parachutes of DRS1 (b) and DRS2 (c) were visible from distance.The white foam shell and release crown are finally also visible; the foam helped to insulate and waterproof DRS2 when it landed on snow.

Table 1 .
Contemporaneous logs from on board SUPERBIT, around the time when two DRS capsules were released.Times are UT on 25 May 2023.SPB logs #1-4 record accurate GPS locations at known times, which we interpolate to the moments of release for DRS2 and DRS1.