Download by parachute: retrieval of assets from high altitude balloons

We present a publicly-available toolkit of flight-proven hardware and software to retrieve 5 TB of data or small physical samples from a stratospheric balloon platform. Before launch, a capsule is attached to the balloon, and rises with it. Upon remote command, the capsule is released and descends via parachute, continuously transmitting its location. Software to predict the trajectory can be used to select a safe but accessible landing site. We dropped two such capsules from the SUPERBIT telescope, in September 2019. The capsules took ∼37 minutes to descend from ∼30 km altitude. They drifted 32 km and 19 km horizontally, but landed within 300 m and 600 m of their predicted landing sites. We found them easily, and successfully recovered the data. We welcome interest from other balloon teams for whom the technology would be useful.


Introduction
High altitude balloon ( ) missions are increasing in number, duration, and expense.Some acquire enough data that transmitting it to the ground would be impossible due to limited bandwidth or cost; others acquire physical samples that must be returned to the ground for full analysis.Mid-flight retrieval could improve a mission's efficiency, by using early results to optimise later data acquisition.Retrieval at any time mitigates the critical risk of total loss if the main hardware were damaged upon landing or lost, e.g. at sea.
Examples of small balloons include the ∼ 2000 radiosondes launched every day for weather forecasting, as well as instruments flown by amateur groups for scientific or educational purposes.Less than 20% of the ∼US$200 radiosondes launched in the USA are recovered, which prohibits upgrades to ∼US$1000 ozonesondes [1], or increases in the number of weather stations, whose sparsity in the Southern hemisphere particularly limits forecasting precision [2].
An example of a large scale mission is the Superpressure Balloon-borne Imaging Telescope [S BIT ; 3, 4].S BIT is an astronomical telescope that rises above 99% of the Earth's turbulent atmosphere to achieve stabilised [5,6] high-resolution imaging at visible and near-UV wavelengths, with a field of view 36 times larger than the Hubble Space Telescope's Advanced Camera for Surveys/Wide Field Camera.S BIT is currently scheduled for a 50-100 day long duration flight, during which it will obtain ∼50 GB of uncompressed science data per day; a successor is already being designed that will obtain 20 times more [7].
Line-of-sight radio communications can achieve 100 Mbps but, on a long duration flight, global satellite communication systems are limited to 1 Mbps (10.5 GB per day), which is not exclusively used for image transfer, and cost up to US$0.50 per MB. 1 We have developed the S BIT Data Recovery System ( ) to recover assets from any balloon, any time it is over land.In default configuration, each capsule includes 5 TB of storage, accessible over wifi ethernet.These are attached to a platform before launch, and ascend as usual.Following a remote command, they descend via parachute, transmitting their location via Iridium message -and continuing to transmit as well as beep audibly after landing.We have also calibrated and tested software to predict the descent trajectory and landing site.This software helps to optimise the moment of release, so the lands safely but accessibly, and assists retrieval on the ground.We successfully used two capsules during S BIT's science commissioning test flight, and intend to use several more during its long duration mission.We also welcome interest from other mission teams for whom the technology would be useful.This paper is organized as follows.Section 2 details safety and other requirements.Section 3 describes the hardware and its release mechanism.Section 4 describes the algorithm we use to predict its landing site.Section 5 describes an end-to-end test of the during the 2019 S BIT commissioning flight.We draw conclusions, and outline plans for future improvements in section 6.

Requirements
This section summarises the main safety requirements for a to be allowed to be jettisonned from a balloon launched by the Canadian Space Agency ( ) and Centre National d'Études Spatiales ( ) from the Timmins Stratospheric Balloon Base in Ontario, Canada in September 2019.The requirements were set in conjunction with the International Civil Aviation Organization's Convention on International Civil Aviation Rules of the Air (Annex 2), but note that requirements may differ at other launch sites or for other agencies.
Relevant safety requirements include (but are not limited to) (R1) Electrical safety: To prevent risk of fire, the gondola and/or must be equipped with a fuse.All cables must be rated for a current greater than the fuse, and must also be insulated, protected, and secured.Electrical connectors must be designed so that there is no ambiguity in their connection.Static charges must be drained away.
(R2) Mechanical safety: The capsule must not detach from the platform unless commanded.In particular, the release mechanism must be sufficiently robust to withstand shocks during launch and descent (in case it is not released).The maximum vertical and horizontal acceleration for a 750 kg payload on a 14 million cubic foot zero-pressure balloon are 6.4g (vertical) and 1.3g (horizontal), which occur during parachute deployment.2We add these in quadrature, with a safety factor of ×2, and adopt a requirement on the to withstand accelerations up to 13g.
(R3) Control of Fault Propagation: Two or more active steps must be taken by an operator to initiate the release of a capsule.In the event of power failure, there must be no change in the state of any safety barrier, and systems must switch to safe mode.It must not be possible for an electrical circuit to be activated as a result of an action on any other circuit, or through the effect of external events.
(R4) Descent safety: As the reaches ground level, it must have vertical speed where m is its mass.3This safety criterion applies to any package with total mass < 2 kg and areal density < 13 g cm −2 , defined as the mass of the package divided by the area of its smallest surface.
To be useful, the must also meet several practical requirements (R5) Easy to find: The must be easy to find after landing, visibly and audibly.
(R6) Labelling: In case the is found by a person not associated with the mission, it must be labelled with a safety warning about the electrical hazards, and contact details for more information or where to return the capsule.(R7) Predictable: It must be possible to predict the descent trajectory and landing site of the within 5 km (requirement) or 1 km (goal), in order to make go/no-go decisions about release.More accurate performance will open more potential landing sites that avoid e.g.towns and lakes, and cluster near remote roads to aid recovery.This code must run in < 30 s, so that accurate decisions can be made about the timing of release from even a fast-moving .A slower but more accurate prediction may also be useful to assist recovery, in the event of communication loss.

Hardware
The hardware design and operations software are open source.4 All components are integrated onto on a custom 300 mm×100 mm printed circuit board (PCB).Throughout this section, numbers in curly brackets refer to component labels in figure 1.
The main function of the is to carry large quantities of science data to the ground and allow its recovery.It is, in effect, 'remote storage with benefits' for the main data acquisition computer (IFC).Data could be transferred into that remote storage either over a wired interface, such as USB or Ethernet, or wirelessly.In the case of S BIT, the IFC and the are physically separated, making USB an unwise choice as, e.g., USB2.0 has a maximum cable length of 5 m.We selected wireless rather than wired Ethernet in order to avoid having to use an 8-way connector, although our experience with low extraction force connectors since then has suggested that an Ethernet interface would work well.
The IFC manages many tasks, such as command forwarding, telemetry downlink, and science camera housekeeping.It is essential that the file transfer into the does not take resources from those operations since the IFC is the gateway to the rest of the S BIT payload.Using 4Available, with full operating instructions, from https://github.com/PaulZC/Data_Recovery_System.
a Raspberry Pi single board computer in the allowed us to implement a wireless or Ethernet interface in a straight forward way.It also simplified the mirroring of files from the IFC into storage, by having essentially a Unix computer at both ends of the transfer.

Enclosure
The PCB is protected by a 3D-printed ABS-like cover, which is manufactured in two identical halves and sealed around the lower two thirds to limit water ingress (with a moisture barrier vent to allow pressure equalisation).5This is enclosed inside a softer outer shell, made from moulded expanding polyurethane (PU) foam.Nylon paracord of diameter 2.4 mm is embedded into the foam, so it can be tied over the top of the cover to secure it; and a nylon sheet lining the mould forms a smooth outer surface on which warnings and contact details can be written in permanent marker (R6).The entire , including parachute and batteries, weighs 1029 grams and has areal density 5.8 g cm −2 .

Power
The capsule will be powered down during most of the mission.This prevents accidental or erroneous release.When the is required, remotely switched (and fused) 12-48 V DC power is supplied from the gondola, via a low extraction force connector {1} with three pins arranged symmetrically and with redundancy on ground (R1).A medical-grade, switch-mode DC-DC converter {2} regulates power to 5 V.The embedded Raspberry Pi computer {3} automatically boots up, enables its Wi-Fi TM network, and connects to the main gondola flight computer.In its current configuration, the uses a power cable with only 3 pins, to minimise the force required to disconnect.Further tests have shown that a connector with 8 pins (arranged in an asymmetric configuration to meet requirement (R1)) will also work, so future versions of the may use wired Ethernet with Power-over-Ethernet.
Immediately before descent, a latching power relay {5} is switched, and two Energizer Ultimate Lithium 9V (PP3) batteries {6} supply similarly regulated {7} power to a tracking subsystem {8-15}.These batteries will henceforth remain powered, and are the only components of the jettisoned that could be considered potentially hazardous (R1).However, they are compliant with safety test criteria T1-T8 defined in Section 38.3 of Ref. [8], which include transportation safety and altitude simulation.Indeed, we have used these batteries without incident in > 30 flights [9].

Raspberry Pi
The Raspberry Pi provides the front-end user interface for the , accessible during the mission via ssh from the main gondola flight computer.For S BIT, it is also the heart of the 'recoverable assets', hosting up to 5 TB of solid-state data storage (1 TB micro SD card that includes the operating system, plus 4 × 1 TB micro SD cards, through 480 MB s −1 USB2.0).Data can be copied to this at any time before release, using gondola power.As a useful backup in case of faults e.g.due to cosmic rays in the space-like environment, data is constantly uploaded instead of all at once right before release.
5The material is similar to ABS, but is a bit easier to work with and does not suffer from the same delamination problems.See https://e3d-online.com/spoolworks-edge.We have also considered using the Raspberry Pis to pre-process and analyse science data during flight, but found they overheated when used for long durations in vacuum and inside the PU foam enclosure: implementing this would require thermal redesign.

Each
capsule is packaged inside a plastic drainpipe (diameter 150 mm, length 350 mm), to limit swinging and to constrain the parachute before release (figure 2).These 'launch tubes' remain attached to the gondola after the is released.Inside each tube is a short power cable and a loop of 2.4 mm diameter nylon paracord.As with our balloon tracking payload [9], the grips the loop using a sprung release-aid mechanism developed for archery, and operated here via a servo {13} stripped, cleaned and re-lubricated with 'space-grease' (Castrol's Braycote 601 EF).The strength of the release mechanism was tested against requirement (R2) by holding the PCB upside-down and hanging 13 kg of lead bricks from the nylon cord.The release mechanism held, and no damage to the PCB or nylon cord was observed.

Two-Step Instructions for Release
Two further actions are required to release the (R3), once the Raspberry Pi is powered up.First, the ground team must ssh into the Raspberry Pi and run a 'Power On' python script, which configures its GPIO pins to switch on the latching relay {5}.A discrete logic protection circuit {4} requires three of the GPIO pins to be in the correct state before the relay is triggered.The pins and states have been selected to prevent the relay from being accidentally triggered as the Pi goes through its boot process.Once the relay is triggered, the 's internal batteries power the microcontroller {8}, which goes through its own start-up procedure and starts to monitor its serial (UART) port for a 'Go' command.The Global Navigation Satellite System ( ) receiver {9} is also powered up and starts to establish a fix.The NMEA messages are sent through the serial port of the microcontroller and logged by the Raspberry Pi.This can be monitored and, if required, the drop can be delayed until it is confirmed that the has established a fix.Second, the ground team must use ssh to run another python script that sends a 'Go' command to the microcontroller via its serial (UART) port, then immediately shuts down the Raspberry Pi. 30 seconds later (time for the Pi to shut down gracefully), the microcontroller enables 5 V power to the servo via a P-channel FET then generates the correct Pulse Width Modulated (PWM) signal to move the servo to the open position.As the is released, the low extraction force connector pulls apart, disconnecting power to the Raspberry Pi, which will remain inactive until recovery.If the 'Go' script is accidentally run before the first 'Power On' script, the script will have no effect as the microcontroller will be unpowered and the 'Go' command ignored.If either of the microcontroller actions fail, e.g.due to its code crashing, the release will not open.

Parachute
The parachute is initially folded on top of the , inside the plastic launch tube (figure 2).It unfolds when the capsule slides out of the white tube.We use a 4 foot (1.22 m) Rocketman parachute, which is expected to slow the descent of our 1029 g payload to terminal velocity < 4 m s −1 at ground level, easily meeting requirement (R4).6It is coloured bright orange, to aid recovery on the ground (R5).7

Tracking and recovery
During descent and after landing, communication is maintained with the via Iridium 9603N satellite modem {10}.The microcontroller alternately switches {11} between monitoring its location vis then transmitting this information via Mobile Originated Iridium SBD messages.A large, helical antenna {12} is shared for these tasks, saving weight while achieving superior performance than a patch antenna, especially after landing horizontally on ground, in trees or on water.A small Radio Frequency (RF) switch is used to connect the antenna to either the or the Iridium modem.The switch shields the during Iridium transmit bursts.This subsystem is a modified version of Ref. [9]'s tracking toolkit.A sounder {15} begins beeping after the 'Go' command is received.Thus a recovery crew can head to coordinates (in a worst case, transmitted immediately before landing), then look for a bright orange parachute and listen for beeps (R5).The sounder can be disabled (or re-enabled), and the frequency with which the reports its location can be adjusted, via Iridium MT message 6See https://the-rocketman.com/recovery-html/. 7Optionally, a second servo {14} and archery release can be used to release the parachute once it has been confirmed to have reached the ground.This option could prevent the from being dragged by the parachute, or allow it to fall to the ground if the parachute has become caught in a tree.However, it introduces a risk of the parachute being released prematurely, through human error.To militate against this risk, the second release can only be opened by sending a Mobile Terminated (MT) SBD message containing a time code.The microcontroller will only respond if the time code matches time to within an appropriate interval; it will ignore (and delete) all other messages, so old queued or erroneous MT messages have no effect.to the .Depending on this frequency, the batteries have an expected operating lifetime of 2-6 weeks.Electrical hazard warnings and contact information written on the nylon surface in permanent marker are easily visible after this time, even in wet conditions (R6).

Software to Predict Descent Trajectories
The key remaining requirement (R7) is software to quickly and accurately predict the landing site of the .
We have adapted open source python code, originally written to simulate the trajectories of tropospheric sounding balloons.8Such trajectories included an ascent phase on a weather balloon and a descent phase of the payload on a parachute.We are principally interested in the descent phase, and have improved and calibrated its accuracy.The code remains open source.9

Weather Models
We use Global Forecast System (GFS) weather models produced by the National Centers for Environmental Prediction (NCEP).They are generated every six hours, at 00:00, 6:00, 12:00, and 18:00 GMT, then become publicly available ∼3.5 hours later (for current weather conditions) to 5 hours later (for a forecast up to 16 days into the future).10 The forecasts include air density, temperature, wind speeds, and geopotential heights in voxels across the globe, with a horizontal resolution of 0.5 degrees, and at 34 air pressure levels, ranging from 1000 mb (low altitude) to 0.4 mb (high altitude).11The geopotential heights represent the height above sea level of a given pressure level.12This is an estimated height based on temperature and pressure data.At relatively low altitudes, the geopotential height is approximately equal to the geometric height.E.g. at the S BIT flight altitude, ∼30 km, the difference is less than 150 m.The models have a vertical resolution between ∼200 m near ground level to 5 km at stratospheric altitudes (∼50 km).
Conditions are forecast with a time resolution of 3 hours.The difference between the production time of forecasts and the trajectory time has a large effect on our accuracy, and so we introduce variable t future , the number of hours a forecast is predicting into the future.For example, for conditions at 16:00, the forecast nearest in time is produced at 12:00 with t future = 3 hours.An ensemble of weather forecasts, generated from slightly perturbed initial conditions, are also available for 9 days (after which their files are deleted, and the main model is moved to archival storage).We have experimented using the ensemble forecasts to estimate uncertainty -but find their variance to be smaller than other sources of uncertainty in our calculations, and cannot access them for historic flights, so do not exploit them.
We require a look-up table of atmospheric conditions at higher resolution than the GFS forecasts.We shall therefore interpolate all variables in vertical columns using a cubic B-spline, in latitude and longitude using bilinear interpolation, then linearly in time.Compared to this scheme, nearest neighbour interpolation degrades the accuracy of our landing site predictions by 28% (4% from spatial interpolation and 23% from temporal interpolation).

Altitude of the ground
For locations with a latitude between -60 and 60 degrees, we use tables of ground altitude as a function of latitude and longitude with a resolution of 1 arcsecond or approximately 30 m at the equator.13For any other latitudes we use tables with slightly lower resolution of 3 arcseconds as the high resolution data are not available for these regions.14At a given location, we assign the altitude of the closest grid point in the tables as the elevation.

Test Flights
We have access to the trajectories of 30 flights in which a real payload ascended by weather balloon then descended via parachute [9].These took place between 2018 and 2019, in Switzerland (20), Greenland (4), and Morocco (6), and are listed in table 1.During each flight, the longitude, latitude, and altitude of the payload was recorded by in ∼5 minute intervals.We exploit these trajectories to calibrate our software and test its accuracy; however, they were not originally intended for this purpose.For example, the payload mass was ∼1.6 kg (and always < 2 kg for legal reasons) but not accurately recorded on each occasion.The parachute was a 7 foot (2.13 m) Rocketman parachute, of the same design as our DRS but larger.Furthermore, the time at which the balloon burst was not recorded (even though it was detected via the on-board accelerometer).At the highest point recorded by , the payload could be either ascending or descending.It was only guaranteed to be descending at the time and location recorded after the highest point.We therefore use this as the initial condition for descent trajectories.

Initial Conditions
The user inputs the starting location, r release =(longitude, latitude) and altitude z, as well as the date and time of release (this defaults to now).If desired, a 'drift time' can be specified, during which the travels horizontally with the platform before release.The code automatically determines and downloads the most appropriate GFS weather data for these inputs.
Upon release, we assume that the instantly reaches terminal velocity.Balancing gravitational acceleration g acting downwards and drag force acting upwards, this is where m is the mass of the payload, ρ is the density of air, A is the area of the parachute, and C d is its coefficient of drag.We initially adopt the manufacturer's design specifications for A and C d (see section 3.6), but calibrate these via free parameter λ (see section 3.6).Both g and ρ depend on altitude; we calculate g(z) assuming the Earth is a perfect sphere with a radially symmetric distribution of mass and interpolate ρ from the GFS weather model.

Iterated Descent Trajectory
We split the descent into altitude steps of height ∆z (we set a requirement on this in section 4.1.1).
For each altitude step, we calculate the time ∆t to descend from top to bottom, assuming that the parachute moves vertically with the terminal velocity evaluated at the midpoint of the altitude step, directly below its starting position.The main strength of this 'leapfrog' method of updating the velocity is that it better conserves the energy of the dynamical system and therefore does not allow the system to drift substantially over time.By using this method, we better approximate the true velocity versus altitude curve than if instead we used the velocity at the beginning of the altitude step.
We neglect updraughts and downdraughts in the GFS model, finding these negligible to the terminal velocity and having no measurable effect on the accuracy of our predicted landing sites.
During each altitude step, we assume that the parachute and payload travel horizontally with North-South ('u') and East-West ('v') wind speeds, again evaluated directly below the starting position, at the midpoint of the altitude step.We update the latitude and longitude of the using the haversine formula, then iterate to the next altitude step.

Termination Criterion
The code iterates the position of the until it reaches sea level (altitude z = 0).This is generally below ground.We do not test for this during descent, because calls to evaluate ground level are relatively slow, and fast horizontal speeds near the ground necessitate a new call at each step.15We instead work backwards from z = 0, checking whether each point in the predicted trajectory was above or below ground.Once we find a pair of coordinates straddling ground level, we interpolate linearly between them to predict the latitude and longitude of the landing site, r.

Convergence Test
The choice of altitude step size ∆z represents a tradeoff between precision and run-time.Run-time is important for real-time predictions of the landing site, to optimise the moment of release from a fast-moving (requirement R7).To predict the landing site r 1 with the greatest possible precision (but slowly), we use altitude step size ∆z = 1 m to calculate trajectories from all the initial conditions in table 1, as a representative sample of possible release locations.We then recompute the trajectories with different step sizes, and record predicted landing sites r ∆z .The mean error r ∆z − r 1m , and the wall-clock runtime on a laptop with a 1.7 GHz CPU are shown in figure 3. Note that during calculation of the trajectories, we did not check for ground elevation.
Predictions for the landing site converge successfully if the altitude step size fully samples the (maximum 200 m) vertical resolution of the GFS models.A practical compromise is ∆z = 100 m.In a runtime of 13 seconds, this achieves a mean landing site precision of 125 m: an error that is subdominant to other sources of uncertainty.All further analysis will be performed with this step size.Red: the root mean square horizontal error in predicted landing site as a function of altitude step size ∆z, compared to the most accurate prediction using ∆z = 1 m.Blue: mean wallclock runtime per trajectory calculation, on a 1.7GHz laptop.In both cases, trajectories are calculated from, and averaged over all 30 initial conditions in table 1.The vertical dashed black line indicates our choice of nominal altitude step ∆z = 100 m that is used for all further analysis in this paper.

Vertical Descent Speeds
We compare the vertical component of the predicted descent speeds to the altitude difference between successive measurements, for 29 of the 30 test flights (figure 4).16The predicted and measured speeds would be equal, if the design specification of the parachute's drag coefficient and area were correct, and the payload masses were recorded correctly.To refine our knowledge of these parameters, we fit the free parameter λ from equation (4.1) across all flights, as The best-fit value is λ bf = 1.019 ± 0.006.There is a marginal evidence that the predicted speeds are approximately correct at high speed (high altitude), but 10-20% too low at low speed (low altitude).This might be due to additional drag in the higher density air -but without further evidence to support and quantify this hypothesis, we shall consider it useful margin in safety requirement (R4), and empirically incorporate it into our uncertainty in the predicted landing sites.; trajectories start on the left and end on the right, with data points recorded every ∼5 minutes.If our trajectory calculation were perfect, the predicted and actual descent speeds would be equal (blue dashed line).The best-fit linear perturbation from this is consistent with the speeds having been overestimated by (3.7 ± 0.4)% (green dotted, which is constrained to pass through the origin).
Bottom panel: residuals of the best fit to the data in the top panel.
In our test data, the payload mass and parachute diameter were not precisely recorded.To test whether these varied between flights, we refit λ for each individual flight.Three flights in particular (2018-03-04 in Switzerland, 2019-05-31 and 2019-07-30 in Morocco) have large (> 4 km) errors in their predicting landing sites (see table 1) and also have the most anomalous values of λ bf .They are so different from λ bf = 1 that either m < 1 kg (unlikely for practical reasons), m > 2 kg (impossible for legal reasons), or (most likely) a different parachute was used.We exclude these three flights from further quantitative analysis.All other 26 test flights have descent rates consistent with a mean value of 1/λ bf = 0.967 ± 0.005.Individual values of λ bf vary by < 20%; if we use these values to recompute the trajectory, the mean error in landing site (compared to the truth) changes negligibly from 2.40 km to 2.37 km.We thus conclude that both the parachutes and payload masses were likely constant for these flights.Nonetheless, because λ bf is always consistent with 1, yet the true payload mass remains uncertain, we henceforth adopt λ = 1 for all further calculations.If the payload masses did vary between flights, this approach will lead to a slight increase in our estimate of uncertainty.However, it should avoid biasing the calculation of future trajectories with different payload masses.

Horizontal Position
The most important aspect of a predicted trajectory is its horizontal accuracy, which culminates in the distance of its predicted landing site from the true landing site, ∆r = (r predicted − r true ).We find that our predicted trajectories are most accurate at high altitude, which is traversed quickly, and near the ground, where the weather forecast is higher resolution and perhaps more accurate (figure 5).
Most of the deviation from the predicted trajectory builds while the parachute descends through the jet stream, where horizontal speeds are also greatest.Thus, the accuracy of our predictions is probably more limited by the accuracy of weather forecasts than the accuracy of our time-stepping algorithm.
We model uncertainty in the predicted landing site as where d predicted is the horizontal distance between the release point and predicted landing site, t future the average t future of the forecasts used at each altitude step in a predicted trajectory -and σ , σ ⊥ , q, σ 0 , h and k are free parameters.In particular, σ (σ ⊥ ) is our model uncertainty in (perpendicular to) the mean direction of predicted travel, and q is the axis ratio between them.We fit the free parameters using Python code [10] to maximise log-likelihood In both cases, the uncertainty is slightly greater in the direction of travel (q > 1); we convert the best-fit parameters into error ellipses on the predicted landing sites.older version of the software than that available on github.17The current version is more accurate in general but -for these particular initial conditions -predicts landing sites within 600 m and 1100 m of the true locations, consistent with the expected uncertainty.Our live runs were noisier, and their 17For example, the 'leapfrog' method of updating the position and velocity discussed in section 4.2.2 was not implemented in the older version of the code.particularly high accuracy was good luck.

Recovery
To aid recovery, the capsules are equipped with a sounder, and the parachutes are bright orange.A recovery crew went to the coordinates of both landing sites, and found both capsules within a few minutes each.They had both fallen to the forest floor (figure 9), so no further action was necessary.
Upon return to the launch facility, the cases were opened to remove batteries and deactivate the sounders (they could have been deactivated remotely, but were in the back of an effectively soundproof truck).A few pine needles had entered the upper chamber of one , but the inner chamber of both capsules was clean.The raspberry Pis were plugged into external power, and the data successfully retrieved.

Conclusions
Retrieving assets from a High Altitude Balloon ( ) platform can mitigate the risk of total loss if the platform is damaged or lost upon landing.Mid-flight retrieval can also increase a mission's efficiency, if its initial performance is assessed, and subsequent operation improved.One solution to retrieve physical samples, or digital data acquired at too high a rate for transmission to the ground, is to jettison a small capsule that descends via parachute.
We have developed, and successfully tested the S BIT Data Recovery System ( ) to 'download' up to 5 TB of data via parachute.We released two capsules from ∼ 30 km altitude during a commissioning flight of the S BIT telescope in September 2019.S BIT is an astronomical telescope that operates in the stratosphere for up to 100 days at a time.Both capsules landed safely, a few hundred metres from their predicted landing sites, and were easily recovered.
Hardware worked as envisaged.Several times during flight, the main gondola logged in to the capsules via 2.4 GHz Wi-Fi TM , and copied data onto them.At two different times, we issued a two-stage 'release' command to one , via ssh.The capsules dropped 30 seconds later, and their parachutes opened.During and after descent, they measured their location via and transmitted it back to the ground station via Iridium message.
Software to predict the descent trajectory also worked well.After travelling a horizontal distance of 31 and 19 km from their release points, the capsules landed within 300 m and 600 m of their expected landing sites.Calibrated on 30 parachute descents from the stratosphere, our software can predict landing sites all over the world with 1σ uncertainty of ∼1.5 km.This uncertainty accumulates most rapidly while the capsules descend through the jet stream.Our software thus appears limited mainly by the accuracy of (GFS) weather models at this altitude.Nonetheless, it satisfies safety requirements to permit immediate release -and it can also be used to predict the best time to release a capsule so that it can be conveniently recovered.This takes the form of a landing strip on the ground, roughly underneath the future path that the software predicts for the platform.
For future flights, we are considering hardware upgrades including -Wired ethernet, for faster data transfer, and to avoid any potential for radio frequency (RF) electromagnetic interference.We have flown 2.4 GHz Wi-Fi TM networks on both and / balloons without any problems, but testing for that interference has frequently slowed payload integration, and has even delayed launch on one occasion.Additionally, this would extend the possible applications for the to Cosmic Microwave Background (CMB) experiments, [e.g.SPIDER; 12], which are extremely sensitive to RF and would be unable to tolerate an onboard Wi-Fi TM network.
-Thermal redesign to enable the Raspberry Pis to pre-process and analyse science data inflight.If power is abundant, a networked collection of Raspberry Pis represents considerable processing power at the start of a mission, precisely the time when decisions are likely needed to assess data quality and update science targets/goals.
-An openable and re-sealable chamber to acquire samples of the biome in the upper atmosphere, to be returned for laboratory analysis on the ground.
During this test with S BIT, we used the capsules as a means to retrieve digital data.However, we envisage that they could be used to retrieve a variety of assets, including hardware or physical samples.We welcome interest from other teams for whom the system may be useful.

Figure 1 .
Figure 1.Left: Front side of the PCB.Middle: Rear side of the PCB.The red numbers refer to the numbers on the block diagram.Right: Block diagram of the PCB.The a1 and a2 indicate the archery release mechanisms 1 and 2 respectively.

Figure 2 .
Figure 2. Two capsules (highlighted by red circles), mounted on the back of the SBIT telescope just before launch on September 17, 2019.The white launch tubes stay attached to the telescope when the capsules are dropped.The PU foam surrounding the circuit boards can be seen protruding from the bottom of the tubes.The cardboard crush pads underneath S BIT are intended to soften impact upon landing.

Figure 3 .
Figure 3.Code convergence test, and tradeoff between precision versus speed.Red: the root mean square horizontal error in predicted landing site as a function of altitude step size ∆z, compared to the most accurate prediction using ∆z = 1 m.Blue: mean wallclock runtime per trajectory calculation, on a 1.7GHz laptop.In both cases, trajectories are calculated from, and averaged over all 30 initial conditions in table 1.The vertical dashed black line indicates our choice of nominal altitude step ∆z = 100 m that is used for all further analysis in this paper.
16Thefailed to record during most of the 2018-08-03 flight in Greenland (most likely due to cold), so we exclude this flight from figure4and all subsequent analysis.

Figure 4 .
Figure 4. Calibration of our parachute descent model, by comparing (only) the vertical speed predicted for and recorded during the 30 test flights.Top panel: the descent speed for each flight (red and black lines for included and excluded flights respectively); trajectories start on the left and end on the right, with data points recorded every ∼5 minutes.If our trajectory calculation were perfect, the predicted and actual descent speeds would be equal (blue dashed line).The best-fit linear perturbation from this is consistent with the speeds having been overestimated by (3.7 ± 0.4)% (green dotted, which is constrained to pass through the origin).Bottom panel: residuals of the best fit to the data in the top panel.

Figure 5 .
Figure 5. Accuracy of trajectories predicted for the descent of 26 parachutes, compared to the true trajectories recorded by.Trajectories begin at the top, and end at the bottom.Left panel: absolute horizontal deviation of each true trajectory from the prediction, at heights above ground level whenever the location was recorded, every ∼5 minutes.Each descent begins from a slightly different altitude.The red line indicates the median of the 26 flights, and the red area indicates the 68.3% region.Right panel: as before, but with the vertical and horizontal distance covered by each trajectory normalised to start or end at the same fractional altitude or horizontal deviation.

Figure 7 .
Figure 7.The predicted trajectory of the first capsule, using GFS weather forecast data available at launch (red), and its actual trajectory recorded by (yellow).The yellow pin labeled 'initial condition' on the top right marks its release location.The yellow pin labeled 'Landing point' marks its predicted landing location, surrounded by red ellipses indicating 1, 2, and 3σ uncertainty.Narrow and wide green cones show the 1 and 3σ predictions from software.The right panel is a zoom of the left.

Figure 8 .
Figure 8.As figure 7, but showing the predicted (red) and(yellow) descent trajectory of the second capsule.The prediction from the software was used before dropping the capsule, but is no longer available for inclusion in this figure.

Figure 9 .
Figure 9. Photos of the two capsules on the ground taken by the recovery team Sébastian Lafrance and Francis Martin.The capsules are indicated by red circles.The parachutes can be clearly seen in bright orange.

Table 1 .
Descent trajectories of real payloads, logged via .We use the top 30 descents to calibrate and test our software.During each of these flights, a payload ascended via weather balloon, then descended via parachute.The exact cutdown point was not recorded, so we list the time, date and location of the first location after its highest: the first moment at which the payload is guaranteed to be descending.The landing site is the mean position of the locations recorded with the same altitude.The range d

Table 2 .
Best-fit parameters for model(4.3) of the uncertainty in predicted landing sites, after predicting all the descents in table 1.The two sets of parameters represent predictions made using only those weather forecasts available before release, or also those spanning the time of release and available shortly after.(∆r ⊥,i ) is the component of ∆r in (perpendicular to) the direction of d predicted , for each descent in table 1.We compute two sets of predicted trajectories.The first set is relevant to assess the safety and optimum timing of a live release, and uses only those weather forecasts that would be available at release (or earlier, to constrain k).The second set is the most accurate that could be made to aid recovery, if communications were lost with DRS capsules immediately after release.These interpolate between weather forecasts available before and after launch, and also use ∆z = 1 m, for a slower but slightly more accurate calculation.
Impact Acceleration Award to Durham University], and UKRI [grant MR/S017216/1].Launch and operational support for the 2019 S BIT flight from Timmins, Ontario was provided by the Centre National d'Études Spatiales ( ) and the Canadian Space Agency ( ).Funding for the development of S BIT is provided by through [grant NNX16AF65G].This work was done in part at JPL, run under a contract for by Caltech.The Dunlap Institute is funded through an endowment established by the David Dunlap family and the University of Toronto.