JPL has now demonstrated a laser communications pointing experiment between two JPL small satellites: ISARA (the receiver) and OCSD (the transmitter). ISARA is a 3U CubeSat that is powered by a novel, deployable Pumpkin solar array that stows around three sides of the 3U structure. The array's three monolithic panels are hinged together, and deploy to present 24 solar cells on top, and a Ka-band reflectarray (that is essentially an RF Fresnel lens), on the bottom. The flatness of these three panels is critical for the performance ISARA's Ka-band system.
In 2018, Pumpkin was the exclusive provider of solar panels for NovaWurks' PODSAT, a short-duration GTO-class mission to validate several concepts of NovaWurks' cellular architecture. PODSAT's primary solar panels used are the exact same models as are currently flying in LEO on NovaWurks' eXCITe mission. Read more about PODSAT here.
On Monday, SpaceX delivered NovaWurks' eXCITe small satellite into LEO orbit. NovaWurks relayed to us on Tuesday that eXCITE's Pumpkin Deployable Clamshell Solar Arrays (DCSAs) using our PMDSAS technology had deployed, were delivering their expected power, and eXCITe was already operational. Small space has become truly responsive.
Pumpkin's relationship with NovaWurks harkens back to the NGC/NovaWorks Mayflower 3U CubeSat mission, for which Pumpkin built a deployable 56W solar array in 2009. No comparable array existed at that time; ten weeks after an initial meeting, Pumpkin had delivered the all-new functional array to NovaWorks, and in 2010 the LEO mission executed successfully, carrying the NGC/NovaWorks core 2U and an additional 1U payload named Caerus from USC/ISI. To date, Mayflower is apparently the highest power-to-weight spacecraft ever built (56W in 4kg), and Pumpkin's 56W array was a critical enabling component.
The 56W Mayflower array was the genesis for Pumpkin's current wide range of PMDSAS(TM) solar arrays. The Pumpkin DCSA on eXCITe uses the fifth generation of Pumpkin's PMDSAS solar panel technology, stows safely in its own clamshell, and when released, deploys to two independent strings of solar cells.
For this eXCITe mission, Pumpkin originally delivered two 112W DCSAs. By the time the various payloads of the eXCITe mission were finalized in 2018, Pumpkin had increased the power of each DCSA array to 176W within the same footprint, thereby demonstrating the overall versatility of the DCSA. Pumpkin also built the fixed solar panels on each HiSat cell in eXCITe. The DCSA and other space-proven Pumpkin PMDSAS solutions are available as COTS offerings.
We wish NovaWurks all the best in this holiday season, for their eXCITe mission.
FLEET Space's Centauri 1 was deposited into its intended orbit by India's PSLV-C43 yesterday, and has already broadcast some initial health and status information.
The Centauri CubeSats Pumpkin built for FLEET Space have best-in-class solar arrays, batteries and structural integrity, along with a 1GHz Linux C&DH platform. Centauri 1 & 2 are comprised of:
When FLEET Space had a last-minute opportunity to launch 3U worth of CubeSats on a Rocket Lab Electron launch vehicle, with the caveat that the CubeSats had to be ready in two weeks (!), they came to Pumpkin. We not only typically have nanosatellite-class equipment in stock, but we also have a proven track record of working quickly on projects that require outside-of-the-box thinking.
Within two weeks, we needed to come up with a working architecture, source the required components / assemblies, make any modifications required, integrate the FLEET payload and antennas (the pixelated portion above), and provide a software framework upon which FLEET could write their mission software.
Given the very short notice and the desire to maximize the utility of the 3U of volume available on this ride, Pumpkin and FLEET settled on a dual-1.5U mission, with two hardware-identical 1.5U CubeSats. We decided to go with a battery-power-only architecture, as that reduced costs and complexity, and fits within the 1.5U available. Pumpkin immediately embarked on creating a new operating mode for our BM 2 battery; within a few days we had this up and running, and Proxima I/II were thus enabled. The two satellite were built with US and Australian teams working together and remotely, then environmentally tested with no issues, and finally delivered to Rocket Lab for LV integration.
Proxima's Pumpkin components included:
The Pumpkin bus components occupy around half the volume and mass of each Proxima CubeSat; FLEET's payload(s) occupy the rest. The GPSRM along with its power-efficient orbit propagator enable Proxima's mission ops, and the low-power 16-bit PPM E3 PIC24 MCU running Salvo along with the BM 2 and its sleep mode guarantee an efficient use of the battery's available energy. Additionally, some of the code from Stanford University's QB50 project was donated to the Proxima mission, and lives on in Proxima I/II. More information on these CubeSats can be found here.
In July 2015, Pumpkin was approached by the Los Angeles County Museum of Art (LACMA) to work with Bahamian artist Tavares Strachan to create a 3U CubeSat-size work of art to be launched into space. Influenced by a visit to the Neues Museum in Berlin, the result of this very successful working relationship between Pumpkin and the artist is a distinctive, unique and beautiful objet d'art, that happens to also carry some hi-tech tags that will simplify its tracking while on orbit.
On Friday, November 2, 2018, the FAA "made a favorable payload determination for the ENOCH payload," and ENOCH is now cleared for launch on the Falcon 9 flight from Vandenberg AFB on November 19. You can read more about ENOCH and the artist behind it here, here and here.
As part of the development of ENOCH, Pumpkin initially considered a scheme whereby ENOCH's canopic jar would be located inside two 1.5U CubeSat "shells" that would separate after launch. However, we ultimately felt that this was not a particularly elegant solution, and given the mass of the jar (it's made of cast brass), surviving shake and shock during the launch to properly separate thereafter would likely prove problematic and frankly, too much trouble. That's when AEK visited the Neues Museum in Berlin and saw Nefertiti's bust in its new home.
Our new approach was to present the canopic jar in a manner that focused the viewer's eyes on the jar, and not on the surrounding materials required for launch. With this new direction for ENOCH, we created a "sled" that is compatible with Planetary System Corporations Canisterized Satellite Dispenser (CSD). This resulted in a design that exposed the canopic jar as much as possible, and let the sled "fade into the background." Hence the deep black color to the sled. This layout meant that the canopic jar was heavily cantilevered at one end, which led to a few iterations when a lower-than-acceptable fundamental frequency was discovered during environmental tests. The base below the canopic jar also incorporates (hidden from view) the requisite hardware to vent the interior volume of the jar, as well as permanent magnets and hysteresis material to help ENOCH establish a stabilized attitude while on orbit. The sled has "feet" on the top and bottom, with an isogridded structure for strength and lightness, for symmetry and in order to satisfy the CSD requirements.
Lastly, since LACMA is not your typical satellite operator, we felt that adding a means to track ENOCH's orbit would be very useful, and so with LACMA's blessing we added three radar retroreflectors supplied by the US Navy to the structure (the white squares). With these radar tags, it will be relatively straightforward to track this "passive" nanosatellite.
We wish the ENOCH mission all the best. A fitting tribute to fallen astronaut Robert Henry Lawrence Jr.
We just finished building two new, custom CubeSats in two weeks. Our customer needed a rapid response to a flight opportunity, and we responded with a mix of Pumpkin COTS components and customer-supplied payloads, all combined in a novel way. You'll be able to learn more about these puppies in more detail once they are on orbit. A big thank-you to all of the Pumpkin employees who went above and beyond their normal duties to complete this project!
2018-11-13 Update: These two CubeSats were launched and deployed over the weekend; you can see some footage of their deployment here. They're launched together from a 3U-size deployer, the one on the right side of the video.
As part of a crash effort to build two customer nanosatellites in two weeks, the reality of typical COTS lead times and a limited budget forced us to adopt a radically simplified approach to the satellite's power system. We decided to run each spacecraft solely from battery power, without any solar panels, etc. Pumpkin's BM 2 intelligent battery module is ideally suited to "battery only" missions, with an energy of up to 100Wh, SoC reporting, independent heaters, and various protections. At 14,000mAh, there's a lot of battery life in the BM 2. The BM 2's typical operating current is 20mA; when an EPS and solar panels are present, the cost of those 20mA is quite minimal. But for a battery-only mission, that's only about one month of operating, powered up, at quiescent currents.
In a spacecraft utilizing only battery power, a smart battery becomes the EPS, because of its ability to isolate loads from the battery's cells. Simple external regulators downconvert the battery voltage to more usable voltages like +5V or +3.3V. There is no need to switch power systems, since everything outside of the battery is unpowered while the battery sleeps.
To implement this functionality, we've added a new software feature to the BM 2 -- a sleep mode. When the BM 2 is sleeping, all power to the rest of the spacecraft is disabled, and the BM 2 maintains an internal "sleeping clock." With the BM 2 sleeping at around 1.5mA, a mission life of around 400 days is possible. Sleep can be commanded with single-minute resolution, with a maximum sleep time of 120 days (7200 hours) via a single command. When in a deep sleep, the BM 2 will wake up every two hours for one minute, giving the flight software the opportunity to cancel the sleep if desired.
The new BM 2 firmware is currently being tested, and is available to all BM 2s built on Rev F1 or later hardware.
We're currently completing a build of 3U-size custom solar panels for a large US Gov't prime. These are an update to panels we have made in the past. We developed a test script that reduced test & verification time for each panel by roughly one hour, making technicians everywhere rejoice! These are PMDSAS 5th-generation solar panels with a polyimide substrate and Spectrolab(R) XTJ rectangular CICs.
I find that a lot of engineers do not understand the role of a Watchdog Timer (WDT) and how to use it properly. In this series I will cover various important aspects of WDTs as applied to embedded systems in general, and to nanosatellites in particular.
The purpose of a WDT is to help the system autonomously recover from a serious error. This recovery is usually in the form of a restart or reset, and after this restart or reset, the system will be in a well-defined initial (and, presumably rather safe and correct) state.
Suppose, for example, that your system included a small piece of code that had not been tested particularly well. Sometime during normal operation, your application found itself in this little code snippet, and from external appearances, stopped working. In reality, this little snippet had an (unintended) infinite loop in it, and this prevented the application from operating normally. But you don't know that; all you know by observing your application is that it suddenly stopped working, it stopped responding to commands, etc. In a situation like this, all you can typically do is press the reset button (I hope you incorporated one in your design), watch the application restart, and then get to the bottom of this problem. Think of a WDT as a reset button that automatically restarts the application when and only when the application software/firmware goes "into the weeds."
WDTs all share a basic behavior; namely, that the application must regularly communicate with the WDT within a certain window of time, or else the WDT will cause the application to restart. WDTs can be internal via software or external in the form of a standalone hardware WDT. When we say that we "kick" the WDT, we mean that we interact with the WDT to prevent it from restarting the application. How and when to kick your WDT is a subject unto itself, that we may cover at a later time. Suffice it to say that you must structure your software/firmware such that whenever your application stops working properly, the result is that the WDT is no longer being kicked, and the system will automatically restart, a short time later.
In the example above, we're stuck in a loop (that presumably doesn't kick the WDT), and so by being stuck in that loop, the Timer part of the WDT expires (because the WDT is not being kicked), and therefore the WDT forces a system reset/restart.
Let's examine the "a short time later" clause, above, and how it may apply to nanosatellites. On a typical nanosatellite, imagine a serious but recoverable software fault (say, one that inadvertently disables the nanosatellite's receivers). Whether the WDT forces a restart in 20ms or 2 minutes or 2 hours or 2 days is up to the designer, though the faster the reset/restart, the less time we'll spend waiting for the system to come back online and receive commands after this software fault. Some nanosatellite power systems have a feature whereby they will power-cycle the entire spacecraft if they don't receive a command or telemetry request within a specified period; this is eminently suited to solve this sort of problem, and is a nice example of a real-world WDT in action. These power systems ignore a system-wide -RESET signal; they neither respond to it, nor do they drive it. Instead, they cycle off and then on all power that is sourced to the other systems in the nanosatellite, and thereby force a system-wide software/firmware restart via Power-On Reset (POR). There are subtleties surrounding a signal like -RESET that we'll explore later in this series.
Now imagine a software fault where a high-pressure propulsion valve gets stuck in the open position due to a software fault. In this case, the nanosatellite can quickly spin out of control and/or exhaust its supply of propellant, should the valve remain energized and open. Here, a WDT with a much faster kick rate (say, at 100Hz) is required to ensure that the valve never stays open for more than 10ms longer than it should. The takeaway here is that some software failures are perfectly well-served by WDTs with long periods, but others require a much faster system response, and hence a "faster" WDT.
In the next installment, we'll explore how the WDT is connected to the rest of a typical nanosatellite.