Flying “Mock CubeSats” on Stratospheric Ballooning Missions

CubeSats are pico-satellites that measure just 10 x 10 x 10 cm (AKA 1U) (or 10 x 10 x 20 cm (2U) or 10 x 10 x 30 cm (3U)). They are typically carried into space inside spring-loaded P-POD launchers as ballast on large rockets. Once in low-Earth orbit, the P-POD cover is opened and CubeSats are ejected overboard. Although CubeSats are tiny and relatively inexpensive, at least by outer-space satellite standards, they can still require tens of thousands of dollars (or more) to develop and many months (sometimes years) to build and test. They also depend on orbital launch opportunities which remain quite rare, even if offered for free by launch providers. We build non-space-rated (AKA “mock”) CubeSat-shaped payloads and test-fly them in a space-like environment on weather balloon flights into the stratosphere. For added realism, our mock CubeSats are carried aloft inside a “mock P-POD” which then opens once in the stratosphere, allowing the CubeSats to dangle free of the P-POD as if they are free-flying. Mock CubeSat developers are challenged to get their data to the ground by radio telemetry (in addition to logging data onboard) – another nod to realism – since outer-space CubeSats are nearly always destroyed during reentry so their onboard data records cannot be recovered. Building and flying mock CubeSats has multiple utilities in education contexts. For schools that develop actual CubeSats for outer space deployment, mock CubeSats can provide introductory training for incoming students as well as a “near-space” option for testing outer space flight hardware and data telemetry radio systems. For schools that do stratospheric ballooning but do not build actual CubeSats (or at least, not yet), developing and flying mock CubeSats can be used as a realistic challenge – especially the size constraints and the radiotelemetry of data – at a far lower cost than building actual CubeSats for outer space missions. Our foray into mock CubeSats began with a freshman seminar and now continues as an ongoing activity in our extracurricular ballooning team. This article will give the most details about one particularly-complicated, albeit realistic, 3U CubeSat which is modeled after “SOCRATES,” our school’s first actual CubeSat. Our mock version of SOCRATES, called “MOC-SOC,” contains a Geiger counter – SOCRATES carries a scintillation detector instead – a 900 MHz FreeWave MM2-T radio, UBLOX GPS, Arduino Mega microcontroller, and four deployable panels on which solar cells can be mounted. The goal of MOC-SOC is to mimic as many parts of the actual SOCRATES mission as possible, which means all of these components are lowerbudget versions of hardware that SOCRATES will contain. MOC-SOC’s mission will be to continuously take data with the Geiger counter, combine this with onboard GPS data, then both log and transmit that data to the ground via 900 MHz radio. After being released from inside the mock P-POD, it will deploy 4 solar panels. Rather than powering the CubeSat, as SOCRATES does, MOC-SOC will just log and transmit solar panel voltage and power data. In this way MOC-SOC mimics the major parts and functionality of SOCRATES on a much lower-budget, yet in an educationally valuable way. Introduction: CubeSats are tiny satellites whose small size, limited functionality/complexity, and modest cost (at least by satellite standards) makes them a good candidate for student hands-on training at the higher education level. NASA’s CubeSat Launch Initiative [Ref. 1] has introductory materials about how CubeSats can be developed from scratch, though launch opportunities remain limited. “Mock” CubeSats are similar in shape and functionality, but are constructed from much less expensive non-space-rated materials and components. Hence mock CubeSats may be even more appropriate as aerospace-hardware build projects at schools with more-limited budgets or, at schools that already have CubeSat programs, for new-student training. After a one-time freshman seminar offering on mock CubeSats [Ref. 2] at the U of MN – Twin Cities, we continue to develop mock CubeSats within our extracurricular Ballooning Team. Once built and ground tested, that team can also launch and operate their devices in a “near-space” environment on stratospheric balloon missions. Building mock CubeSats has been valuable for both novice and experienced ballooning students alike, even if they don’t ultimately join our actual CubeSat team. CubeSat size constraints, plus the challenge of implementing data telemetry (since actual CubeSats aren’t ever recovered, so on-board logs aren’t available), force the students to (a) design very compact experiments, (b) learn how to implement radio telemetry, and (c) utilize various types of CAD fabrication techniques to build structures out of a wider array of materials than are typically used for stratospheric ballooning payloads. Mock CubeSat Systems We have made mock CubeSat structural frames out of sheet aluminum, fiberglass, and Lexan (all shaped with a water jet cutter), plus foam-core (for practice only) and medium-density fiberboard (MDF), a pressed wood product (shaped with a laser cutter), as well as 3D-printed ABS or PLA plastic. CAD software is used to design the shapes and produce the files used by the cutting tools and 3D printers. Comparable results could be obtained, admittedly with more manual effort, using standard machine-shop and/or hand tools. Indeed, CAD-fabricated parts often require finishing touches done by hand. Electronic contents of mock CubeSats range from non-telemetry items typically used in stratospheric ballooning such as microcontroller-logged sensor suites, video cameras, and offthe-shelf sensor modules that do not require wiring and programming. More ambitious mock CubeSats include short-range (dozens of meters) XBee radios, to send data and receive commands from nearby (i.e. elsewhere on the stack) communication relay units (AKA Comms units) equipped with radios that can provide uplink and downlink between ground stations and payloads in the stratosphere. The most realistic, and most complicated, mock CubeSats are the ones that contain long-range (dozens of kilometers) radios that can communicate with ground station radios directly. To expand the realism of the flight experience, we use a mock P-POD container to enclose mock CubeSats while they are lifted by weather balloon into the stratosphere. The mock P-POD is made of Styrofoam so it provides some thermal protection to the mock CubeSats until they are above the tropopause. The mock P-POD then opens an end-cover to “deploy” the mock CubeSats, letting them dangle fully exposed to the stratospheric (AKA near-space) environment. Like actual P-PODs, our mock P-POD can accommodate a single 3U mock CubeSat or else combinations of 1U and 2U mock CubeSats which add up to no more than 3U. The end-cover deployment mechanism on the mock P-POD is servo based and is controlled by a microcontroller on the mock P-POD itself. Depending on the mission, deployment can be triggered by gps, by a timer, and/or by radio command either from a nearby payload (like from a mock CubeSat inside the P-POD) or from a ground station. Redundancy is built into the system to try to ensure mock CubeSat deployment at a reasonable point in the ascent, even if the primary triggering mechanism fails. AEM 1805 (freshman-projects class): Modulus (1U), SPARTA (2U), CSI (2U) We first attempted building and flying mock CubeSats in a freshman-projects class entitled “Introduction to CubeSats (with Stratospheric Balloon Flight)” [Ref. 1]. The ten students in that class learned to wire and program microcontroller sensor suits then, working in 3 teams, used CAD to design and fabricate one 1U mock CubeSat and two 2U mock CubeSats. The frames and the attempted functionality of the three mock CubeSats were intentionally different from one another, to test “by trial and error” what worked. All three mock CubeSats were battery-powered since our stratospheric balloon flights only last for 2 to 3 hours, so solar power and battery recharging were not required. The 1U mock CubeSat was called “Modulus” (see Figure 1). Its frame was made of aluminum and it contained a Razor IMU M0 which is a combination microcontroller and 9 degree of freedom inertial measurement unit (IMU). The physically largest sensor onboard was an RM60 Geiger counter from Aware Electronics to measure radioactivity, but the team also incorporated pressure, temperature, humidity, and temperature sensors, a couple of which were in powered by a solar panel as a proof of concept. Sensor data was logged onboard and a fraction of it was transmitted by XBee (short-range) radio to a Comms payload, to be relayed to a ground station. Modulus also listened, by XBee radio, for uplink commands (relayed by Comms) from the ground. One 2U mock CubeSat was called “CSI” which stood for “Camera Satellite Initiative” (see Figure 2). Its frame was made of MDF with aluminum rails on the corners. It contained a Raspberry Pi computer, more powerful than a microcontroller, plus an RFD-900 (long-range) radio to communicate with a ground station while in flight. It also had an XBee radio, so it could serve as a communications relay itself, plus a Raspberry Pi camera to take still pictures which it could theoretically send to the ground by radio link though sending photos through the RFD-900 system was very slow so we suspected this was unlikely to work very well. The Raspberry Pi also logged data including gps, sensor data, and radio traffic, for post-flight comparison to telemetry data, plus still photos taken by the camera. The original CSI design included a servo to rotate a filter wheel in front of the camera to take pictures through various colored and polarized filters, but this feature was dropped prior to flight. The second 2U CubeSat was called “SPARTA” which stood for “Solar Panel and Radio Testing Artifice” (see Figure 3). Its frame was completely 3D-printed. The main purpose of SPARTA was to test a FreeWave MM2-T (long-range) radio system, controlled by an Arduino Uno microcontroller, to compare its performance to the RFD-900 radio system in CSI. SPARTA also had two deployable panels on which solar cells were mounted, to see if it could open a solar panel array in flight using a tungsten hot-wire cutter. SPARTA also contained an AIM XTRA; a commercial gps-enabled rocketry altimeter with multiple onboard sensors including temperature, pressure, 3-axis accelerometer, 3-axis magnetometer, and 3-axis gyro. A mock P-POD built for class use that included realistic aluminum corner rails, as well as a spring system to eject the mock CubeSats once the cover was released. Ground testing revealed that the mock CubeSats would jam upon deployment if the mock P-POD was oriented horizontally – the original plan – so ultimately the P-POD was flown vertically and the mock CubeSats fell out gravitationally, making the spring system superfluous (though outer-space PPODs do use springs to eject CubeSats). After design, construction, and an admittedly-modest amount of ground testing, Modulus (1U) plus SPARTA (2U) were flown in a single mock P-POD (see Figure 4) and, on a separate balloon, CSI (2U) plus a simple 1U shell containing off-the-shelf HOBO data loggers were flown in a second mock P-POD. SPARTA and CSI each had their own ground station – Modulus talked to the ground through a separate non-CubeSat-shaped Comms payload which had its own ground station (so each student team operated a ground station). Students prepped the mock CubeSats, integrated them into the mock P-PODs, set up their ground stations, assisted with launching the balloon, then did as much ground (radio) operations as they could during the flight. The mock P-PODs were located at the bottom of their respective stacks so the mock CubeSats, once released, would hang freely below the mock P-PODs without tangling with lines to lower payloads. The mock CubeSats frames were tied directly to the P-PODs using four lengths of 50pound braided fishing line. As described below, we later regretted making those final two decisions. Suffice it to say that the class flight, though educational, was not a resounding success. All 3 teams struggled to get their mock CubeSats closed and to keep them running and talking to their ground stations while being enclosed in the mock P-PODs (even before balloon release). During the flight the mock P-PODs on both balloons did deploy the mock CubeSats late in the ascent, as planned. But in-flight data telemetry to launch site (AKA “uprange”) ground stations, directly from SPARTA and by radio relay from Modulus, was spotty at best. The CSI team struggled to maintain radio contact with their mock CubeSat from the launch site and their “downrange” ground station, located near the predicted burst location so as to be closer to the balloon at altitude, never picked up radio transmissions at all. Telemetry issues aside, the mock CubeSats were literally “too free” once they were out of their P-PODs and hanging at the bottom of their stacks. We suspect they were tossed around so violently that their retaining strings either snapped or, more likely, broke the mock CubeSat parts to which they were tied. SPARTA, being 3D printed, was particularly susceptible to structural failure, and Modulus hung below SPARTA so depended on SPARTA to stay attached. At about 40,000 feet during descent SPARTA finally broke free and fell to the ground, independent of the rest of the stack, including the P-POD, which came down safely by parachute. Telemetry from an AIM XTRA gps-enabled rocketry altimeter in SPARTA allowed us to track its fall almost all the way to the ground, probably with Modulus still attached. SPARTA landed in a swamp, and stopped transmitting on impact, so we were unable to locate and recover either SPARTA or Modulus despite a ground search of the area. Both the Modulus and SPARTA teams were only able to do final reports based on incomplete and often poor-quality telemetry data, since their onboard data logs were not recovered (much-like an outer-space CubeSat mission, though not intentional in this case). Some Lessons Learned (from freshman-projects class) Despite the set-backs, students in the freshman class learned a lot about CubeSats, both mock and real, and also about challenges of stratospheric ballooning. Here are some of the main lessons learned:  Building payloads to CubeSat size constraints is hard! Some designs that looked good “on paper” (actually “in CAD”) turned out to be very impractical to build and/or operate. The mock CubeSats were all very hard to assemble, with wires pulling loose (and worse!) on flight day. Some later designs (see below) with components mounted on removable sleds were more challenging to design but easier to service and operate, once assembled.  The original mock P-POD was somewhat “too realistic” (see Figure 6.) The spring system to eject the mock CubeSats did not work for horizontal deployment in a standard gravitational environment – the mock CubeSats would jam – but was not needed when the mock P-POD was flown vertically so mock CubeSats could just be dropped out the bottom. The metal rails in the mock P-POD were removed in later designs as well, to save weight.  Mock CubeSat structures may not be strong enough to survive the stresses applied by rigging during balloon flights, especially if hanging free from the bottom of stacks. After our experience losing 2 mock CubeSats during the freshman class flight we decided to start integrating mock CubeSats into mock P-PODS by placing them in tough “cases” built of foam-core (for padding, not thermal protection), strapping tape (for strength), and tubing (to accommodate standard ballooning rigging) (see Figure 7). We also started to fly P-PODs mid-stack, rather than at the very bottom, so once deployed mock CubeSats would slide down rigging lines (see Figure 7) but still be somewhat constrained by line tension due to even-lower payload(s) on the stack. Additional Mock CubeSat Ideas List Although the freshman class and not been retaught (yet), mock CubeSat development is now an ongoing activity in our extracurricular Ballooning Team (see Figure 8). Mock CubeSat shells can be made of many different kinds of materials, not just low-density materials like Styrofoam and foam-core usually used in ballooning payloads. To date we have constructed shells out of aluminum, 3D printed plastic, MDF, Lexan, acrylic, and fiberglass and used CAD for design and for laser cutting, water jet cutting, and 3D printing. Sides can be held together with aluminum brackets and machine screws and nuts, like actual CubeSats, as well as with zip ties, strapping tape, and glues/epoxies. The use of thin “cases” made of foam-core and strapping tape for integration and rigging means that we no longer need to worry (as much) about mock CubeSat shell overall strength, nor about things like glue joints getting brittle and potentially cracking in the cold. As for contents and functionality, the mock CubeSats we have developed include components from one or more of the following categories:  Off-the-shelf components (on-board data logging but no data telemetry, little or no programming and wiring required): Neulog sensor modules, HOBO sensor modules, PocketLab sensor modules, GoPro (or other) video or still cameras, etc.  Microcontroller-based sensor suites (on-board data logging plus XBee (short range) data telemetry to nearby “Comms” radio relay payload): microcontrollers – Arduino (Mega, Uno, Nano, etc.), Teensy (mostly v3.5 or v3.6 with microSD card logging built in), Raspberry Pi (v3, v2, Zero, with ribbon cable to Raspberry Pi video/still camera) plus sensors – pressure, temperature, relative humidity, light (visible, UV, IR), Geiger counter (cosmic radiation), 3-axis accelerometers, 3-axis gyros, 3-axis magnetometers, etc.  Microcontroller-based sensor suites (on-board data logging plus RFD900 radio or FreeWave MM2-T radio (long range) with data telemetry directly to ground station): microcontrollers & sensors – same as above.  Commercial gps-enabled radios (must be very small – antenna might stick out of shell): o AIM XTRA gps flight computer http://entacore.com/electronics/aimxtra o FeatherWeight gps tracker https://www.featherweightaltimeters.com/featherweight-gps-tracker.html o StratoTrack aprs transmitter https://www.highaltitudescience.com/products/stratotrack-aprs-transmitter  Radio beepers (non-gps), requires a directional ground receiver o Units for tracking rc planes http://www.com-spec.com/rcplane/index.html Case Study: MOC-SOC The most complicated mock CubeSat we have developed to date is MOC-SOC (see Figure 9), so-named because it is a mock version of SOCRATES, a real CubeSat currently nearing completion at the University of Minnesota. SOCRATES is a 3U CubeSat that uses a scintillation detector to study (a) X-rays from the Sun and also (b) gamma rays from distant astronomical sources for potential use for deep space navigation by comparing arrival times of high energy events with arrival times at other (much-larger) gamma ray detectors whose location in space is well known. After preliminary data processing and reduction, results are sent down through a network of widely spaced ground stations. SOCRATES is powered through solar cells which are affixed to four deployable panels on the outside of the main structure. In order to mimic some key aspects of SOCRATES’ functionality, MOC-SOC uses a Geiger counter to detect cosmic radiation. Geiger counts, logged by an Arduino Mega microprocessor, are both recorded on a micro-SD card and automatically transmitted to a ground station using a FreeWave MM2-T radio once every 30 seconds. A UBLOX gps module, also connected to the Mega, allows MOC-SOC to tag Geiger counter data with accurate time, latitude, longitude, and altitude readings. Some of these components can be seen in Figure 10 which shows the exterior and interior of MOC-SOC. Like typical CubeSats, SOCRATES will be powered through solar cells. MOC-SOC, on the other hand, only needs to run for a 2 to 3 hour stratospheric balloon flight so it is powered with lithium 9-volt batteries. In order to mimic the look and operation of SOCRATES, MOC-SOC also has four deployable “solar panels.” These will initially be folded up against the body of MOC-SOC then will be released (to open through windows in the case) using a “SMART” servo-motor actuated release mechanism intentionally after MOC-SOC is deploying from the mock P-POD, much like actual CubeSats are not allowed to begin operations until some minutes after they are ejected from an actual P-POD. Because MOC-SOC’s “solar panels” are not being used to provide power, we simply attached one solar cell to a single panel and monitored its voltage during the flight as evidence that it could have provided some power. The deployable panels can be seen in Figure 9. They are each attached to the body of MOC-SOC by two 1-inchlong hinges cut from a steel measuring tape. Such tape measure hinges are used on SOCRATES (and many other CubeSats). We hoped they would be strong enough to hold the deployed panels perpendicular to the body of MOC-SOC (which flies with long axis vertical, with hinges at the bottom). However we found that the MDF panels, even without solar cells covering them, were too heavy for the measuring tape hinges to support in a gravitational field. Thus we used fishing line to hold the panels in prior to servo actuation, then to keep panels from folding out beyond horizontal once released (see Figure 9). We have had the opportunity to fly MOC-SOC once and, as often seems to be the case, the experience was educational but actual results were mixed. Like its most-direct predecessor, SPARTA, MOC-SOC was challenging to assemble. Indeed, the SMART release mechanism was broken during assembly so the panels were not constrained and opened up immediately after it was released from the mock P-POD. Despite successful radio testing prior to the flight, once we were preparing to launch we were unable to connect our ground station to the FreeWave radio onboard MOC-SOC. This meant that MOC-SOC flew in fully-autonomous mode and we were unable to monitor its performance, much less command it, during the flight. After recovering MOC-SOC and opening it up, no small task (which is why we didn’t do this prior to the flight, with a balloon inflated and ready to fly) we found that a wire connecting the antenna to the radio had come detached. Since we have flown this radio in the past and never had this happen, we assume it was most likely human error when assembling MOC-SOC. Going forward we may reconsider the design from an ease-of-assembly and ease-of-troubleshooting perspective. From the onboard data log on the micro-SD card, we know that MOC-SOC got continuous data from the Geiger counter and the solar cell (which was not exposed to the Sun until after MOC-SOC left the mock P-POD and the panels unfolded). However the u-blox gps never got a gps fix – another surprise – meaning the data log had neither time or latitude/longitude/altitude stamps. We can estimate time based on data line number, since data was recorded at a regular rate, and estimate altitude by comparing time-in-flight with other tracking records. But the data would have been much easier to analyze had MOC-SOC been able to put time and gps stamps on the data directly. A look-up video camera placed on the payload directly below the mock P-POD captured the drop of MOC-SOC and the immediate deployment of its panels. The mock P-POD was supposed to open based on altitude data sent from MOC-SOC by XBee radio as the primary method of release, with command from the ground (using the FreeWave radio system) as back-up. A timer backed up both those methods. MOC-SOC did not have a gps fix so it never told the P-POD to open. We were unable to contact MOC-SOC from the ground, so we didn’t command the opening either. Thus the mock P-POD must have opened due to the backup timer. Although MOC-SOC did fly, did come out of the mock P-POD at a reasonable point in the flight, did deploy its panels, did log both Geiger counter data and solar panel data, and was recovered with relatively little damage on its first flight, we were unable to confirm its radio connection to the ground, unable to test its SMART release, and unable to get a gps lock (for tagging data with time and gps information). We intend to keep working on troubleshooting the design and hope to re-fly MOC-SOC in the future and successfully exercise more of its functionality. This is another advantage of mock CubeSats flown on stratospheric balloon missions – they aren’t one-shot experiments. If they don’t work correctly it is (usually) possible to recover the hardware, fix/develop it further, and re-fly it. Conclusions Designing and building mock CubeSats is an educationally-valuable activity, challenging students to work within very tight space constraints to accomplish scientific and engineering objectives and relay results to the outside world by radio telemetry (if required). Flying mock CubeSats into “near-space” on stratospheric balloon missions makes the experience even more like a real CubeSat mission, but at a tiny fraction of the cost. We find that mock CubeSats are a valuable addition to hands-on training as an extension for students already doing stratospheric ballooning, even those who are very experienced, and/or as an introduction for students getting involved in building actual CubeSats for deployment into outer space. Despite experiencing setbacks, several students from the freshman projects class described above went on to develop more-advanced mock CubeSats, including MOC-SOC, whereas other students from that same class went on to become long-time participants in the actual SOCRATES CubeSat program. Acknowledgements: The original offering of a freshman-projects class on mock CubeSats was supported by the Dean of the College of Science and Engineering (CSE) and by the Aerospace Engineering and Mechanics (AEM) Department at the University of Minnesota – Twin Cities, as well as by the Minnesota Space Grant Consortium (MnSGC). We are thankful for guidance provided by the SmallSat team at the University of Minnesota – Twin Cities who are developing SOCRATES and other genuine CubeSats for outer space operation. References: 1. NASA CubeSat Launch Initiative resources, including “CubeSat 101” introductory book: https://www.nasa.gov/content/cubesat-launch-initiative-resources 2. AEM Department write-up about AEM 1805 Introduction to CubeSats freshman class: https://www.aem.umn.edu/info/spotlight/AEM_1805_CubeSats.shtml. Additional class details and sample materials available upon request. (Aside: class website, not reachable outside of U of MN, is http://www.aem.umn.edu/courses/aem1805/spring2017/) 3. University of Minnesota – Twin Cities Modifications to the Montana State University Telemetry System for Stratospheric Eclipse Ballooning, Geadelmann et. al, AHAC 2017, https://via.library.depaul.edu/cgi/viewcontent.cgi?article=1134&context=ahac Fig. 1. “Modulus” – a 1U mock CubeSat with an all-aluminum shell containing a Razor M0 9-degree-of-freedom IMU/microcontroller, Geiger counter, multiple other sensors (see list in text), body-mounted solar panels, and an XBee (short range) radio for data telemetry to the ground through a nearby “Comms” radio-relay payload flying on the same balloon stack. Fig. 2. “CSI (Camera Satellite Initiative)” – a 2U mock CubeSat with MDF walls and aluminum corners containing a Raspberry Pi miniature computer with Raspberry Pi camera, RFD900 (long range) radio, and an XBee (short range) radio. CSI is essentially a re-mounting in a 2U form factor of the “still image payload” developed by the MT Space Grant for the Space Grant Eclipse Ballooning Project modified by the MN Space Grant to serve as a communications relay [Ref.3]. The left photo is pre-flight; the right photo is the innards of CSI after a rather hard landing. Fig. 3. “SPARTA (Solar Panel and Radio Testing Artifice)” – a 2U mock CubeSat that was entirely 3D printed containing an AIM XTRA commercial gps-enabled rocketry altimeter plus a FreeWave MMT-2 (long range) radio to communicate with a ground station at the launch site. SPARTA had two panels which deployed in flight, on which were mounted solar cells. Fig. 4. Rigging Modulus to hang below SPARTA, then inserting both into a single mock P-POD. That P-POD was flown at the bottom of the stack under one weather balloon. CSI, plus another basic 1U mock CubeSat, were flown in a different P-POD under a second weather balloon. Fig. 5. On the left – “up-range” (i.e. at launch site) ground station to communicate with the FreeWave MMT-2 radio in SPARTA. On the right – “down-range” (i.e. near predicted burst location) ground station ready (but unable) to communicate with the RFD900 radio in CSI. Fig. 6. Photo of the original mock P-POD showing aluminum rails and plate with springs below – both of these “overly-realistic” features were later dropped (see discussion in main text). Fig. 7. On the left – mock CubeSat “cases” for padding (not thermal) protection plus tubing for standard balloon payload rigging. On the right – after deployment from the mock P-POD the cases (empty in this test), plus bottom cover, slide down rigging lines (toward payload below). Fig. 8. Photos/CAD diagrams of additional mock CubeSats. From left to right: (A) “FrankenSat” shell, to try various materials, (B) “AIM XTRA / Featherweight” 1U cube with 3D printed shell, (C) “QUIIC system (with XBee radio) / PocketLab” 1U cube with aluminum shell, (D) “GoPro / HOBO” 1U cube with MDF shell. Some cubes have one transparent side, to put on exhibit. Fig. 9. On the left – MOC-SOC, completely sealed but with panels open, shortly before putting it into the P-POD. On the right – View inside MOC-SOC. The Geiger counter is on the lower left. Fig. 10. On the left – Still photo from an up-looking video showing MOC-SOC post-deployment during flight. Camera was mounted on the side of a payload so the image is partially obscured. On the right – MOC-SOC after landing, with extended “solar” panels, below the mock P-POD.


Introduction:
CubeSats are tiny satellites whose small size, limited functionality/complexity, and modest cost (at least by satellite standards) makes them a good candidate for student hands-on training at the higher education level. NASA's CubeSat Launch Initiative [Ref. 1] has introductory materials about how CubeSats can be developed from scratch, though launch opportunities remain limited.
"Mock" CubeSats are similar in shape and functionality, but are constructed from much less expensive non-space-rated materials and components. Hence mock CubeSats may be even more appropriate as aerospace-hardware build projects at schools with more-limited budgets or, at schools that already have CubeSat programs, for new-student training.
After a one-time freshman seminar offering on mock CubeSats [Ref. 2] at the U of MN -Twin Cities, we continue to develop mock CubeSats within our extracurricular Ballooning Team. Once built and ground tested, that team can also launch and operate their devices in a "near-space" environment on stratospheric balloon missions.
Building mock CubeSats has been valuable for both novice and experienced ballooning students alike, even if they don't ultimately join our actual CubeSat team. CubeSat size constraints, plus the challenge of implementing data telemetry (since actual CubeSats aren't ever recovered, so on-board logs aren't available), force the students to (a) design very compact experiments, (b) learn how to implement radio telemetry, and (c) utilize various types of CAD fabrication techniques to build structures out of a wider array of materials than are typically used for stratospheric ballooning payloads.

Mock CubeSat Systems
We have made mock CubeSat structural frames out of sheet aluminum, fiberglass, and Lexan (all shaped with a water jet cutter), plus foam-core (for practice only) and medium-density fiberboard (MDF), a pressed wood product (shaped with a laser cutter), as well as 3D-printed ABS or PLA plastic. CAD software is used to design the shapes and produce the files used by the cutting tools and 3D printers. Comparable results could be obtained, admittedly with more manual effort, using standard machine-shop and/or hand tools. Indeed, CAD-fabricated parts often require finishing touches done by hand.
Electronic contents of mock CubeSats range from non-telemetry items typically used in stratospheric ballooning such as microcontroller-logged sensor suites, video cameras, and offthe-shelf sensor modules that do not require wiring and programming. More ambitious mock CubeSats include short-range (dozens of meters) XBee radios, to send data and receive commands from nearby (i.e. elsewhere on the stack) communication relay units (AKA Comms units) equipped with radios that can provide uplink and downlink between ground stations and payloads in the stratosphere. The most realistic, and most complicated, mock CubeSats are the ones that contain long-range (dozens of kilometers) radios that can communicate with ground station radios directly.
To expand the realism of the flight experience, we use a mock P-POD container to enclose mock CubeSats while they are lifted by weather balloon into the stratosphere. The mock P-POD is made of Styrofoam so it provides some thermal protection to the mock CubeSats until they are above the tropopause. The mock P-POD then opens an end-cover to "deploy" the mock CubeSats, letting them dangle fully exposed to the stratospheric (AKA near-space) environment. Like actual P-PODs, our mock P-POD can accommodate a single 3U mock CubeSat or else combinations of 1U and 2U mock CubeSats which add up to no more than 3U. The end-cover deployment mechanism on the mock P-POD is servo based and is controlled by a microcontroller on the mock P-POD itself. Depending on the mission, deployment can be triggered by gps, by a timer, and/or by radio command either from a nearby payload (like from a mock CubeSat inside the P-POD) or from a ground station. Redundancy is built into the system to try to ensure mock CubeSat deployment at a reasonable point in the ascent, even if the primary triggering mechanism fails. AEM 1805 (freshman-projects class): Modulus (1U), SPARTA (2U), CSI (2U) We first attempted building and flying mock CubeSats in a freshman-projects class entitled "Introduction to CubeSats (with Stratospheric Balloon Flight)" [Ref. 1]. The ten students in that class learned to wire and program microcontroller sensor suits then, working in 3 teams, used CAD to design and fabricate one 1U mock CubeSat and two 2U mock CubeSats. The frames and the attempted functionality of the three mock CubeSats were intentionally different from one another, to test "by trial and error" what worked. All three mock CubeSats were battery-powered since our stratospheric balloon flights only last for 2 to 3 hours, so solar power and battery recharging were not required.
The 1U mock CubeSat was called "Modulus" (see Figure 1). Its frame was made of aluminum and it contained a Razor IMU M0 which is a combination microcontroller and 9 degree of freedom inertial measurement unit (IMU). The physically largest sensor onboard was an RM60 Geiger counter from Aware Electronics to measure radioactivity, but the team also incorporated pressure, temperature, humidity, and temperature sensors, a couple of which were in powered by a solar panel as a proof of concept. Sensor data was logged onboard and a fraction of it was transmitted by XBee (short-range) radio to a Comms payload, to be relayed to a ground station. Modulus also listened, by XBee radio, for uplink commands (relayed by Comms) from the ground.
One 2U mock CubeSat was called "CSI" which stood for "Camera Satellite Initiative" (see Figure 2). Its frame was made of MDF with aluminum rails on the corners. It contained a Raspberry Pi computer, more powerful than a microcontroller, plus an RFD-900 (long-range) radio to communicate with a ground station while in flight. It also had an XBee radio, so it could serve as a communications relay itself, plus a Raspberry Pi camera to take still pictures which it could theoretically send to the ground by radio link though sending photos through the RFD-900 system was very slow so we suspected this was unlikely to work very well. The Raspberry Pi also logged data including gps, sensor data, and radio traffic, for post-flight comparison to telemetry data, plus still photos taken by the camera. The original CSI design included a servo to rotate a filter wheel in front of the camera to take pictures through various colored and polarized filters, but this feature was dropped prior to flight.
The second 2U CubeSat was called "SPARTA" which stood for "Solar Panel and Radio Testing Artifice" (see Figure 3). Its frame was completely 3D-printed. The main purpose of SPARTA was to test a FreeWave MM2-T (long-range) radio system, controlled by an Arduino Uno microcontroller, to compare its performance to the RFD-900 radio system in CSI. SPARTA also had two deployable panels on which solar cells were mounted, to see if it could open a solar panel array in flight using a tungsten hot-wire cutter. SPARTA also contained an AIM XTRA; a commercial gps-enabled rocketry altimeter with multiple onboard sensors including temperature, pressure, 3-axis accelerometer, 3-axis magnetometer, and 3-axis gyro.
A mock P-POD built for class use that included realistic aluminum corner rails, as well as a spring system to eject the mock CubeSats once the cover was released. Ground testing revealed that the mock CubeSats would jam upon deployment if the mock P-POD was oriented horizontallythe original planso ultimately the P-POD was flown vertically and the mock CubeSats fell out gravitationally, making the spring system superfluous (though outer-space P-PODs do use springs to eject CubeSats).
After design, construction, and an admittedly-modest amount of ground testing, Modulus (1U) plus SPARTA (2U) were flown in a single mock P-POD (see Figure 4) and, on a separate balloon, CSI (2U) plus a simple 1U shell containing off-the-shelf HOBO data loggers were flown in a second mock P-POD. SPARTA and CSI each had their own ground station -Modulus talked to the ground through a separate non-CubeSat-shaped Comms payload which had its own ground station (so each student team operated a ground station). Students prepped the mock CubeSats, integrated them into the mock P-PODs, set up their ground stations, assisted with launching the balloon, then did as much ground (radio) operations as they could during the flight. The mock P-PODs were located at the bottom of their respective stacks so the mock CubeSats, once released, would hang freely below the mock P-PODs without tangling with lines to lower payloads. The mock CubeSats frames were tied directly to the P-PODs using four lengths of 50pound braided fishing line. As described below, we later regretted making those final two decisions.
Suffice it to say that the class flight, though educational, was not a resounding success. All 3 teams struggled to get their mock CubeSats closed and to keep them running and talking to their ground stations while being enclosed in the mock P-PODs (even before balloon release). During the flight the mock P-PODs on both balloons did deploy the mock CubeSats late in the ascent, as planned. But in-flight data telemetry to launch site (AKA "uprange") ground stations, directly from SPARTA and by radio relay from Modulus, was spotty at best. The CSI team struggled to maintain radio contact with their mock CubeSat from the launch site and their "downrange" ground station, located near the predicted burst location so as to be closer to the balloon at altitude, never picked up radio transmissions at all.
Telemetry issues aside, the mock CubeSats were literally "too free" once they were out of their P-PODs and hanging at the bottom of their stacks. We suspect they were tossed around so violently that their retaining strings either snapped or, more likely, broke the mock CubeSat parts to which they were tied. SPARTA, being 3D printed, was particularly susceptible to structural failure, and Modulus hung below SPARTA so depended on SPARTA to stay attached. At about 40,000 feet during descent SPARTA finally broke free and fell to the ground, independent of the rest of the stack, including the P-POD, which came down safely by parachute. Telemetry from an AIM XTRA gps-enabled rocketry altimeter in SPARTA allowed us to track its fall almost all the way to the ground, probably with Modulus still attached. SPARTA landed in a swamp, and stopped transmitting on impact, so we were unable to locate and recover either SPARTA or Modulus despite a ground search of the area. Both the Modulus and SPARTA teams were only able to do final reports based on incomplete and often poor-quality telemetry data, since their onboard data logs were not recovered (much-like an outer-space CubeSat mission, though not intentional in this case).

Some Lessons Learned (from freshman-projects class)
Despite the set-backs, students in the freshman class learned a lot about CubeSats, both mock and real, and also about challenges of stratospheric ballooning. Here are some of the main lessons learned:  Building payloads to CubeSat size constraints is hard! Some designs that looked good "on paper" (actually "in CAD") turned out to be very impractical to build and/or operate.
The mock CubeSats were all very hard to assemble, with wires pulling loose (and worse!) on flight day. Some later designs (see below) with components mounted on removable sleds were more challenging to design but easier to service and operate, once assembled.  The original mock P-POD was somewhat "too realistic" (see Figure 6.) The spring system to eject the mock CubeSats did not work for horizontal deployment in a standard gravitational environmentthe mock CubeSats would jambut was not needed when the mock P-POD was flown vertically so mock CubeSats could just be dropped out the bottom. The metal rails in the mock P-POD were removed in later designs as well, to save weight.  Mock CubeSat structures may not be strong enough to survive the stresses applied by rigging during balloon flights, especially if hanging free from the bottom of stacks. After our experience losing 2 mock CubeSats during the freshman class flight we decided to start integrating mock CubeSats into mock P-PODS by placing them in tough "cases" built of foam-core (for padding, not thermal protection), strapping tape (for strength), and tubing (to accommodate standard ballooning rigging) (see Figure 7). We also started to fly P-PODs mid-stack, rather than at the very bottom, so once deployed mock CubeSats would slide down rigging lines (see Figure 7) but still be somewhat constrained by line tension due to even-lower payload(s) on the stack.

Additional Mock CubeSat Ideas List
Although the freshman class and not been retaught (yet), mock CubeSat development is now an ongoing activity in our extracurricular Ballooning Team (see Figure 8). Mock CubeSat shells can be made of many different kinds of materials, not just low-density materials like Styrofoam and foam-core usually used in ballooning payloads. To date we have constructed shells out of aluminum, 3D printed plastic, MDF, Lexan, acrylic, and fiberglass and used CAD for design and for laser cutting, water jet cutting, and 3D printing. Sides can be held together with aluminum brackets and machine screws and nuts, like actual CubeSats, as well as with zip ties, strapping tape, and glues/epoxies. The use of thin "cases" made of foam-core and strapping tape for integration and rigging means that we no longer need to worry (as much) about mock CubeSat shell overall strength, nor about things like glue joints getting brittle and potentially cracking in the cold.
As for contents and functionality, the mock CubeSats we have developed include components from one or more of the following categories:  Off-the-shelf components (on-board data logging but no data telemetry, little or no programming and wiring required): Neulog sensor modules, HOBO sensor modules, PocketLab sensor modules, GoPro (or other) video or still cameras, etc.  Microcontroller-based sensor suites (on-board data logging plus XBee (short range) data telemetry to nearby "Comms" radio relay payload): microcontrollers -Arduino (Mega, Uno, Nano, etc.), Teensy (mostly v3.5 or v3.6 with microSD card logging built in), Raspberry Pi (v3, v2, Zero, with ribbon cable to Raspberry Pi video/still camera) plus sensorspressure, temperature, relative humidity, light (visible, UV, IR), Geiger counter (cosmic radiation), 3-axis accelerometers, 3-axis gyros, 3-axis magnetometers, etc.  Microcontroller-based sensor suites (on-board data logging plus RFD900 radio or FreeWave MM2-T radio (long range) with data telemetry directly to ground station): microcontrollers & sensorssame as above.  Commercial gps-enabled radios (must be very smallantenna might stick out of shell):  Figure 9), so-named because it is a mock version of SOCRATES, a real CubeSat currently nearing completion at the University of Minnesota. SOCRATES is a 3U CubeSat that uses a scintillation detector to study (a) X-rays from the Sun and also (b) gamma rays from distant astronomical sources for potential use for deep space navigation by comparing arrival times of high energy events with arrival times at other (much-larger) gamma ray detectors whose location in space is well known. After preliminary data processing and reduction, results are sent down through a network of widely spaced ground stations. SOCRATES is powered through solar cells which are affixed to four deployable panels on the outside of the main structure.
In order to mimic some key aspects of SOCRATES' functionality, MOC-SOC uses a Geiger counter to detect cosmic radiation. Geiger counts, logged by an Arduino Mega microprocessor, are both recorded on a micro-SD card and automatically transmitted to a ground station using a FreeWave MM2-T radio once every 30 seconds. A UBLOX gps module, also connected to the Mega, allows MOC-SOC to tag Geiger counter data with accurate time, latitude, longitude, and altitude readings. Some of these components can be seen in Figure 10 which shows the exterior and interior of MOC-SOC.
Like typical CubeSats, SOCRATES will be powered through solar cells. MOC-SOC, on the other hand, only needs to run for a 2 to 3 hour stratospheric balloon flight so it is powered with lithium 9-volt batteries. In order to mimic the look and operation of SOCRATES, MOC-SOC also has four deployable "solar panels." These will initially be folded up against the body of MOC-SOC then will be released (to open through windows in the case) using a "SMART" servo-motor actuated release mechanism intentionally after MOC-SOC is deploying from the mock P-POD, much like actual CubeSats are not allowed to begin operations until some minutes after they are ejected from an actual P-POD. Because MOC-SOC's "solar panels" are not being used to provide power, we simply attached one solar cell to a single panel and monitored its voltage during the flight as evidence that it could have provided some power. The deployable panels can be seen in Figure 9. They are each attached to the body of MOC-SOC by two 1-inchlong hinges cut from a steel measuring tape. Such tape measure hinges are used on SOCRATES (and many other CubeSats). We hoped they would be strong enough to hold the deployed panels perpendicular to the body of MOC-SOC (which flies with long axis vertical, with hinges at the bottom). However we found that the MDF panels, even without solar cells covering them, were too heavy for the measuring tape hinges to support in a gravitational field. Thus we used fishing line to hold the panels in prior to servo actuation, then to keep panels from folding out beyond horizontal once released (see Figure 9).
We have had the opportunity to fly MOC-SOC once and, as often seems to be the case, the experience was educational but actual results were mixed. Like its most-direct predecessor, SPARTA, MOC-SOC was challenging to assemble. Indeed, the SMART release mechanism was broken during assembly so the panels were not constrained and opened up immediately after it was released from the mock P-POD. Despite successful radio testing prior to the flight, once we were preparing to launch we were unable to connect our ground station to the FreeWave radio onboard MOC-SOC. This meant that MOC-SOC flew in fully-autonomous mode and we were unable to monitor its performance, much less command it, during the flight. After recovering MOC-SOC and opening it up, no small task (which is why we didn't do this prior to the flight, with a balloon inflated and ready to fly) we found that a wire connecting the antenna to the radio had come detached. Since we have flown this radio in the past and never had this happen, we assume it was most likely human error when assembling MOC-SOC. Going forward we may reconsider the design from an ease-of-assembly and ease-of-troubleshooting perspective.
From the onboard data log on the micro-SD card, we know that MOC-SOC got continuous data from the Geiger counter and the solar cell (which was not exposed to the Sun until after MOC-SOC left the mock P-POD and the panels unfolded). However the u-blox gps never got a gps fixanother surprisemeaning the data log had neither time or latitude/longitude/altitude stamps. We can estimate time based on data line number, since data was recorded at a regular rate, and estimate altitude by comparing time-in-flight with other tracking records. But the data would have been much easier to analyze had MOC-SOC been able to put time and gps stamps on the data directly.
A look-up video camera placed on the payload directly below the mock P-POD captured the drop of MOC-SOC and the immediate deployment of its panels. The mock P-POD was supposed to open based on altitude data sent from MOC-SOC by XBee radio as the primary method of release, with command from the ground (using the FreeWave radio system) as back-up. A timer backed up both those methods. MOC-SOC did not have a gps fix so it never told the P-POD to open. We were unable to contact MOC-SOC from the ground, so we didn't command the opening either. Thus the mock P-POD must have opened due to the backup timer.
Although MOC-SOC did fly, did come out of the mock P-POD at a reasonable point in the flight, did deploy its panels, did log both Geiger counter data and solar panel data, and was recovered with relatively little damage on its first flight, we were unable to confirm its radio connection to the ground, unable to test its SMART release, and unable to get a gps lock (for tagging data with time and gps information). We intend to keep working on troubleshooting the design and hope to re-fly MOC-SOC in the future and successfully exercise more of its functionality. This is another advantage of mock CubeSats flown on stratospheric balloon missions -they aren't one-shot experiments. If they don't work correctly it is (usually) possible to recover the hardware, fix/develop it further, and re-fly it.

Conclusions
Designing and building mock CubeSats is an educationally-valuable activity, challenging students to work within very tight space constraints to accomplish scientific and engineering objectives and relay results to the outside world by radio telemetry (if required). Flying mock CubeSats into "near-space" on stratospheric balloon missions makes the experience even more like a real CubeSat mission, but at a tiny fraction of the cost. We find that mock CubeSats are a valuable addition to hands-on training as an extension for students already doing stratospheric ballooning, even those who are very experienced, and/or as an introduction for students getting involved in building actual CubeSats for deployment into outer space. Despite experiencing setbacks, several students from the freshman projects class described above went on to develop more-advanced mock CubeSats, including MOC-SOC, whereas other students from that same class went on to become long-time participants in the actual SOCRATES CubeSat program. Fig. 1. "Modulus"a 1U mock CubeSat with an all-aluminum shell containing a Razor M0 9-degree-of-freedom IMU/microcontroller, Geiger counter, multiple other sensors (see list in text), body-mounted solar panels, and an XBee (short range) radio for data telemetry to the ground through a nearby "Comms" radio-relay payload flying on the same balloon stack.

Fig. 2.
"CSI (Camera Satellite Initiative)"a 2U mock CubeSat with MDF walls and aluminum corners containing a Raspberry Pi miniature computer with Raspberry Pi camera, RFD900 (long range) radio, and an XBee (short range) radio. CSI is essentially a re-mounting in a 2U form factor of the "still image payload" developed by the MT Space Grant for the Space Grant Eclipse Ballooning Project modified by the MN Space Grant to serve as a communications relay [Ref.3].
The left photo is pre-flight; the right photo is the innards of CSI after a rather hard landing. Fig. 3. "SPARTA (Solar Panel and Radio Testing Artifice)"a 2U mock CubeSat that was entirely 3D printed containing an AIM XTRA commercial gps-enabled rocketry altimeter plus a FreeWave MMT-2 (long range) radio to communicate with a ground station at the launch site.
SPARTA had two panels which deployed in flight, on which were mounted solar cells. Fig. 4. Rigging Modulus to hang below SPARTA, then inserting both into a single mock P-POD. That P-POD was flown at the bottom of the stack under one weather balloon. CSI, plus another basic 1U mock CubeSat, were flown in a different P-POD under a second weather balloon.

Fig. 5.
On the left -"up-range" (i.e. at launch site) ground station to communicate with the FreeWave MMT-2 radio in SPARTA. On the right -"down-range" (i.e. near predicted burst location) ground station ready (but unable) to communicate with the RFD900 radio in CSI. 6. Photo of the original mock P-POD showing aluminum rails and plate with springs below -both of these "overly-realistic" features were later dropped (see discussion in main text).

Fig. 7.
On the left -mock CubeSat "cases" for padding (not thermal) protection plus tubing for standard balloon payload rigging. On the rightafter deployment from the mock P-POD the cases (empty in this test), plus bottom cover, slide down rigging lines (toward payload below).   On the right -MOC-SOC after landing, with extended "solar" panels, below the mock P-POD.