Data Downloaded via Parachute from a NASA Super-Pressure Balloon

Abstract

In April 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 and 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 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.

1. Introduction

The Super-pressure Balloon-borne Imaging Telescope [1] (superBIT) was raised to ∼33 km altitude by nasa’s 18.8 million cubic foot super-pressure balloon 728NT (https://www.csbf.nasa.gov/map/balloon10/flight728NT.htm). It was launched on 16 April 2023 from Wanaka, New Zealand, was carried east by seasonal polar vortex winds [2], 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 [3]. Early in the mission, data were transmitted to ground stations via Starlink and tdrss satellite communication 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 was stored on board, as well as on redundant sets of solid-state drives within drop packages. Several copies of the full dataset were released via parachute prior to the termination of the flight and were safely recovered. The superBIT payload was entirely destroyed upon landing, and although, in this case, the data were eventually recovered from the remains of the onboard 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 [4] (and receive commands to, e.g., turn on or off a beeper). 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 the performance of software that we use to predict their decent trajectory. Accurate predictions of the descent vector are essential in choosing a safe landing zone. Neither the trajectory of the main telescope payload nor the parachute is 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 design (https://github.com/PaulZC/Data_Recovery_System) and software (https://github.com/EllenSirks/pyBalloon) are both open-source. Their success inspired nasa’s ‘floating dragon’ Balloon Challenge (https://floatingdragon.nianet.org/). 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 the loss of communications, loss of payload, or destruction of payload upon landing. Our experience suggests that teams should take the offer.

2. Upgraded Hardware Design

Each drs capsule comprised a Raspberry Pi 3B attached to a custom 300 mm × 125 mm printed circuit board (pcb; see Figure 1). The capsules were powered by switchable 24 V DC from the main payload while they were attached, then by two internal 9 V lithium batteries after release. These batteries were the only components of the drs that could be considered potentially hazardous. However, they were compliant with safety test criteria T1–T8 defined in Section 38.3 of [5]. The drs used 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 issued a sequence of three commands (to prevent errors and fault propagation) that used a servo inside the drs to open the pincer, allowing the drs to drop away.

Each drs was enclosed in a 3D-printed cpe hard plastic case and a closed-cell foam shell (see Figure 2). One case was printed in pla, which also works fine but is harder to handle because it is brittle. The foam shell could absorb impacts and add a degree of waterproofing, which proved useful when one drs landed in snow. It was 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 [6]. The total mass including the parachute was 1.28 kg.

2.1. Alignment and Attachment to the Main Payload

To prevent the drs from swinging while hanging 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 attached a 3D-printed petg ‘crown’ to the top of the drs (see Figure 2). This fit into an inverted crown that was fixed to the main gondola. The crowns were kept together, and the drs was held secure by pulling the cable tie taut.

A second pincer mechanism held a 4 foot parachute folded inside a spacer above the drs. This size parachute yields a terminal velocity ∼4 m s${}^{-1}$. This was fast enough to reduce the downrange travel distance (hence, uncertainty in the predicted landing spot, which allowed us to avoid populated areas) while keeping kinetic energy comfortably below a 15 J safety requirement to note cause serious injury or damage.

2.2. Hardwired Ethernet to the Main Payload

It was 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 [7] (e.g., SPIDER;), we use hardwired Ethernet for the 2023 science flight. Inside the drs, this involved 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) joined at zero-extraction force connectors (Smiths Interconnect Hypertac^® connectors, part numbers D02PB906FSTAH and D02PB906MSTH) that would separate easily when the drs was released. Two-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.

2.3. Thermal Management

During the 2019 engineering flight, each drs worked for only ∼15 min 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 a thermal emissivity coefficient $e=0.95$, the main cpu would reach 42.5 ${}^{\circ }$C while executing a simple Python script (the Raspberry Pi itself was reporting a cpu temperature of 49.4 ${}^{\circ }$C), and the usb sockets would reach 48.9 ${}^{\circ }$C when a 5 GB file was 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 milled a 53 g aluminium heat sink/radiator that sits between the Raspberry Pi and the pcb. It was held against the cpu by a spring glued to the pcb, and contact was ensured with thermal paste. The aluminium block extended through a 56 mm × 14 mm hole in the plastic case, ending flush with that, and was covered with Mylar tape to increase its infrared emissivity. The heat was 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{}^{\circ }$C [8]. For what it is worth, we also stuck a thin, off-the-shelf copper radiator to the ram chip on the back.

To reduce heat production at the usb sockets, we used two 6” usb extension cables to relocate two sd card readers (they ended up sitting roughly behind the microcontroller).

We also operated each drs on a 5 min on–20 min off rota: powering up each in turn, copying data, then powering down. During a typical cycle during the night (day), the cpu temperature would increase by 3.0 ± 0.3 ${}^{\circ }$C (3.7 ± 1.0 ${}^{\circ }$C) in 5 min (see Figure 4). On one occasion during night 13, drs1 was powered for two cycles, and its temperature rose 14.7 ${}^{\circ }$C (from $-11.6{}^{\circ }$C to 3.1 ${}^{\circ }$C) in 30 min. It continued operating throughout this time and cooled half-way back to the same temperature as the others in approximately 2 h. We do not know why drs1 ran at $-8.2\pm 8.6{}^{\circ }$C ($4.7\pm 11.2{}^{\circ }$C) during the night (day), consistently a few degrees warmer than drs2 at $-11.4\pm 8.1{}^{\circ }$C ($1.0\pm 10.7{}^{\circ }$C) and drs5 at $-11.9\pm 7.4{}^{\circ }$C ($-1.2\pm 10.6{}^{\circ }$C).

Before launch, four drs capsules were mounted underneath the rest of the payload (see Figure 5). They were oriented with their radiators towards the front of the telescope (which was never allowed to point towards the Sun) and enclosed by a loose skirt of Mylar, the inside of which was aluminised except for a ∼45${}^{\circ }$ pleat near the radiator. On two sides, an additional sunshield of foam wrapped in aluminised Mylar also protected the drss from incidental knocks. drs1 was at the back left, drs2 at the back right, drs3 at the front right, and drs5 at the front left (drs4 was our flight spare). Power and Ethernet cables were routed from each drs up to superBIT.

2.4. Data Storage

Each drs was fitted with $5\times 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 booted, a custom script compared files on the payload with those on the drs (matching name and size because some files, such as instrument timestreams, continually grow) and copied new data to an sd card with sufficient space. superBIT’s rate of data acquisition was 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’ abilities 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 intermittent faults 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 failed during testing, so these were discarded.

2.5. 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 that 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.

3. Descent and Recovery

We initially intended to release one drs capsule around mission day 40, 60, 80, and 100, whenever superBIT passed over land, to mitigate the risk of the payload and all its onboard 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 observations 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 on board and separated from the main payload.

3.1. 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 the release commands were received at 12:30:58 and 12:31:25 UT. Taking into account an intentional 30 s 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 interpolated between these to infer the location of superBIT at the moments when drs capsules were released (see

Table 1. Contemporaneous logs from onboard superBIT around the time when two drs capsules were released. Times are UT on 25 May 2023. spb logs #1–4 recorded accurate GPS locations at known times, which we interpolated to the moments of release for drs2 and drs1.

Event	Time (UT)	Latitude [deg]	Longitude [deg]	Altitude [m]
spb log #1	12:29:33	$-47.685$	$-70.518$	32,585
spb log #2	12:30:37	$-47.692$	$-70.475$	32,488
Release of drs2	12:31:28	$-47.696$	$-70.444$	32,439
spb log #3	12:31:40	$-47.697$	$-70.437$	32,428
Release of drs1	12:31:55	$-47.699$	$-70.421$	32,323
spb log #4	12:32:44	$-47.707$	$-70.367$	31,981

). During the 27 s between release events, superBIT travelled 1.79 km on heading 101${}^{\circ }$.

3.2. Predicted Descent Trajectories

We predict the drs descent trajectories and landing sites with PyBalloon software [6] 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}^{\circ }$ and a flight time of ∼32 min. 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 min 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 predicted landing sites for drs1 at $-47.{8594}^{\circ }$, $-69.{6307}^{\circ }$ (altitude 878 m), and drs2 at $-47.{8557}^{\circ }$, $-69.{6559}^{\circ }$ (altitude 920 m), with 68% confidence limits of ${\sigma }_{\Vert }=2.1$ km in the main direction of motion and ${\sigma }_{\perp }=1.9$ km perpendicular to that. With even more hindsight, we were able to interpolate between gfs model wind speeds issued before and after the drs release. These lengthened the model descent vectors by ∼1.1 km, to predicted landing sites for drs1 at $-47.{8655}^{\circ }$, $-69.6153$ (altitude 863 m) and drs2 at $-47.{8600}^{\circ }$, $-69.{6444}^{\circ }$ (altitude 850 m), with 68% confidence limits ${\sigma }_{\Vert }=2.3$ km and ${\sigma }_{\perp }=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.

3.3. Reported Landing Sites

Unfortunately, neither drs reported or recorded its location during descent as they were 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 lines 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 were 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}^{\circ }$, $-69.{59300}^{\circ }$ (altitude 786 m) and drs2 at $-47.{86368}^{\circ }$, $-69.{67452}^{\circ }$ (altitude 806 m), after averaging over several readings to provide ∼2 m precision. These locations are 66.5 km and 58.3 km horizontally from their release points, respectively, 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 appears 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 had to extrapolate uncertainties from most of the test drops used to calibrate our model [6]. 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 best-guess 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}^{\circ }$ below the horizontal. The two capsules started only 1.8 km (and 27 s) apart but ended up separated by 6.4 km.

3.4. 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 later from the unreleased drs and the main data store on superBIT (which also had slightly more telemetry data). However, superBIT had been completely destroyed upon landing, when its parachute failed to detach (perhaps because of 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.

4. Results

The drs system comprised both hardware and software. Hardware worked reliably throughout the mission in three of the four capsules. They were power cycled every 15 min 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 was further corrupted on either the central data store or the drs capsules.

The internal batteries in the drs capsules became 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 an 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 might 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 was 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.

5. 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 may be provided by a standard Ethernet socket and plug with the retaining lug removed. Power over Ethernet can 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 will 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 [6], 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 have helped 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.