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.
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:
After a three year design, leading to today and after finally (for the first time) snapping the top panel on our 1.5U CubeSat and having everything fit perfectly, I just had to stop in celebration and come over and send this Email.
It just fits. Everything in the 1.5U frame just fit together perfectly. Especially since we have a 1.2kg central ballast (for longer orbit) and total 1.5U mass of 2.8 kg.
The one mod I made was a small 0.1” notch at each of the corners of the side fame so that when it has slid down over the top of our full stack and the 1.2kg central mass (which is the precise dimensions of the walls so it can be screwed to the walls), that I can then use a small screwdriver at each corner post to get the side frame “started” when I go to remove it.
Without those slots, the fit of the side sleeve to the bottom is so perfect that there is nothing to get in there and pry it loose. Attached is stack photo.
Bob Bruninga, PE
US Naval Academy
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.
Pumpkin supplies solar panels to a wide range of nanosatellites through our proprietary Pumpkin Modular Deployable Solar Array Systems (PMDSAS) technology, now in its sixth generation.
We just received word that the solar panels on the 3U BGUSat CubeSat continues to work perfectly 7 months into the BGUSat mission. Pumpkin built a series of deployable solar panels in engineering model and flight unit form for BGUSat. BGUSat utilizes a somewhat unusual topology, with a 5S+2S arrangement of seven solar cells per panel. Additionally, BGUSat used Pumpkin's CubeSat Hinges, four of Pumpkin's Panel Release Mechanism (PRM) to release each of the panels, along with a Pumpkin COTS 3U CubeSat Kit structure. When deployed, the solar panels are in a single plane, in a "propeller" configuration.