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.

AEK

There's a reason why we refer to our Chief Mechanical Engineer Adam Reif as "Close Tolerance Reif," or CTR. Pumpkin customers benefit from Adam's obsession with turning out a quality product at a good price. The U.S. Naval Academy's Bob Bruninga sent us a thank-you email yesterday, as USNA was completing the assembly of their PSAT2, which utilizes a COTS Pumpkin 1U structure:

Bob relates that PSAT2 is "Built by students for self training in radio art and only using Alumni GIFT funds." More info is available at http://aprs.org/psat2.html

Image courtesy of United States Naval Academy

From the joint JPL-Pumpkin ISARA project that began in 2012, today the 3U ISARA spacecraft is on-orbit and undergoing initial trials. ISARA is equipped with a deployable 24-cell Pumpkin PMDSAS solar array that also has a Ka-band reflectarray antenna on its backside. The conductive pattern on the reflectarray side is analogous to a Fresnel lens for Ka-band wavelengths, implemented as discrete patches arranged in a particular pattern. Pumpkin worked with Dr. Richard Hodges and his group at JPL to develop a process whereby the JPL-designed reflectarray could be incorporated into Pumpkin's PMDSAS deployable solar panel technology and manufacturing, to yield flat and extremely stiff dual-purpose panels. Naturally, Pumpkin's space-grade hinges were used on these panels. 

In the images above, you can see the backside of the deployed Pumpkin 3-panel solar array + reflectarray. The metallic-color pieces between the panels are the Pumpkin hinges that enable the reflectarray to wrap around the ISARA structure when stowed. Solar power (from the solar cells on the opposite sides of these panels, not visible in these images) is routed from the central panel into the 3U bus at the hinge interface located at the base of the center panel. The smaller 4x4 array of patches on the opposite side of these fisheye-view images captured on orbit is the feed antenna for the reflectarray.

Dr. Hodges reported on January 16 that the Pumpkin solar array is functioning properly. The Aerospace Corporation is currently doing checkout of the various spacecraft bus components (e.g., Star Tracker and ACS). We wish them luck with this ground-breaking effort!

On-orbit images courtesy of JPL / NASA. More information at https://www.jpl.nasa.gov/cubesat/missions/isara.php.

The Australian government's Defense Science & Technology Group's Buccaneer Risk Mitigation Mission (BRMM) CubeSat launched on Saturday aboard the penultimate Delta II launch, from Vandenburg AFB.  DST Group has been in contact with Buccaneer, successfully  updated some critical configuration parameters, and will now "settle into a normal tempo of spacecraft operations."

Buccaneer is a 3U MISC 3-class nanosatellite with full 3-axis attitude control and RF payload(s). Pumpkin developed the bus, structure, and deployable solar panels, and integrated the UHF, S-band and GPS antennas, Panel Release Mechanisms (PRMs), various bus sensors and other mission-specific components. As part of our typical fixed-firm price (FFP) nanosatellite offerings, this MISC 3 is highly customized for DST Group. Payload integration was verified virtually via CAD exchanges, and then physically in Australia, without any Pumpkin intervention.

Pumpkin is registered with DDTC and can perform ITAR-affected work for entities outside of the USA, subject to license approval.

We wish DST Group the best with their BRRM CubeSat, and hope to work with them again in the future.

Twelve complete 2U CubeSat Kit skeletonized chassis are ready to ship. Each chassis consists of a dual-switch Baseplate Assembly, a 2U Chassis Walls, and a Cover Plate Assembly; all skeletonized. This is a repeat customer in the USA. We wish them luck with their future mission(s)!

NovaWurks is set deploy one of its Hyper-Integrated Satlets (HISats) from the ISS later this week. Pumpkin has partnered with NovaWurks (formerly NGC's NovaWorks) since 2010 on cutting-edge small space technology. In 2010, Pumpkin built the world's first deployable 56W solar array for NGC's NovaWork's Caerus/Mayflower 3U CubeSat, all on a handshake and in ten weeks. More recently, Pumpkin has partnered with NovaWurks on the development of a variety of small satellite technologies, two of which are on the ISS HISat. Pumpkin's space-grade products enable both modular and high-power energy collection within the HISat architecture.

Additionally, Pumpkin advised Stanford University's SSDL on its SNAPS 0.2U-size imager, an autonomous HD-video capture device for tethered use on microsats. The ISS HISat will utilize SNAPS in the upcoming mission. Former SSDL students involved in SNAPS are excited to see their efforts finally get to orbit!

We wish NovaWurks all the best with their HISat architecture. More information on this deployment is available online. There is also a nice overview of HISat and this mission at NASA.

The U.S. Army SMDC's Kestrel Eye II M imaging microsat has deployed from the ISS, and first contact was made at 08:01 CDT today. Kestrel Eye was built by Adcole Maryland (formerly Maryland Aerospace, Inc (MAI)). Pumpkin was involved in the early development of the first Kestrel Eye (originally called NanoImageSat), supplying the C&DH module and prototype 35mm image capture subsystem. 

Pumpkin has delivered multiple solar panels to another SMDC program with spaceflight heritage -- SMDC One, a 3U CubeSat-based system.

Pumpkin has worked with Adcole Maryland / MAI since 2008 on integrating their MAI-100 and MAI-400 ADACS into a variety of Pumpkin 3U and 6U CubeSats, including the NRO's Colony I program (MAI-100), and various Pumpkin MISC 3 and 6U SUPERNOVA spacecraft (MAI-400 with dual IR Earth Horizon Sensors). We congratulate Adcole Maryland on their most recent success -- they've earned it!

More information on the Kestrel Eye II deployment is available online.