Chips in Space: Lessons learned (Part 2)

For those who have been following this blog and the reader comments, you know that the battery failed eight days into the mission. For the next mission, we need to design a power system where a shorted battery will not render the satellite inoperable. Thankfully, the ARISSat-1 battery failed open; but that was luck. For an extraordinary story about amateur-satellite batteries, read how the battery shorted then reopened 21 years later on AMSAT OSCAR 7.

With ARISSat-1’s perpetual off-in-eclipse and on-in-sunlight operation, we should consider adding a real time clock (RTC) to keep chronological time. This would also be helpful in the event the satellite reboots. Presently, ARISSat-1 keeps mission elapsed (MET) time in seconds from when it was last powered on. With the battery failed and the satellite effectively rebooting each orbit, the MET from the telemetry shows when it was last powered on. So, we have to use time of receipt to maintain the chronology of the telemetry.

Which leads me to another lesson learned—adding non-volatile memory for storing whole-orbit data. Whole-orbit data would be sampled at a known rate. This would give us the ability to analyze trends better. Presently, the telemetry is transmitted down on an “as gathered” basis.


And, in what likely will not be the last word on telemetry, Jerry Zdenek (N9YTK) adds:

“Pay more attention to the accuracy of the data. [For example] It'd be nice to have greater than 10 bits on the battery current.”

Another lesson we learned was to use a real-time operating system (RTOS) for the larger microcontrollers in the system. The ARISSat-1 firmware was written using a simple scheduler scheme. We initially thought this would provide the simplest solution. However, as we got further into the project, the team felt it really was more trouble than it was worth. An RTOS would make life a lot simpler.


When designing the subsystems, insert plenty of debugging points—the more the better. You can’t have too few! And, if you stack the PCBs, as was done in the Internal Housekeeping Unit (IHU), ensure that you can use some sort of backplane or extender boards. Jerry, on his experience with the IHU stack:

“Debugging something in the middle of the stack (of course the one that needs it) was a nightmare. I had to build a bunch of different right-angle adapters and a few jumper cables to connect all the other jumpers.  The Software Defined Transponder (SDX) was 90 degrees to the top; the Power Supply Unit (PSU) was 90 degrees to the bottom, jumpered to the IHU in a second spot. It was really ugly.”

We call this creating a “flat-sat,” with all of the PCBs and subsystems laid out flat on a table. Everything connected and communicating in what will become the final configurations. This allows the programming, debugging and probing of test points.  However, there’s another catch—plan ahead on how to debug and reprogram the satellite when it is all closed up. When everything is “buttoned up,” it’s a real pain to open everything up to get at a particular test point, programming port and what have you, in order to implement a change. Dismantling and reassembling is a recipe for disaster.


Closing out our Lessons Learned series, Jim Johns (KA0IQT) had an interesting, if not unique, perspective from the project:

“As far as lessons learned, I suspect that most of the team will focus on the technical challenges.  In my opinion, the bigger lesson learned was that the project was an ‘MBA in a Box’ (or in this case satellite.) Looking back, all of the normal disciplines that are covered in an MBA program were an integral part of the project. Organizational Behavior (the study of the relationships among management and teams), Operations Research (methods of optimizing processes and procedures, and decision making), Finance and Accounting (developing the financial strategy and tracking the costs of the program), and Marketing (the strategy to use in selling the product). In short, the project provided an opportunity to learn and grow both technically and managerially.”

And here we thought this project was all technical challenges!

The design team has put together a survey for everyone interested in this satellite project, including you, the loyal readers of this blog. We’d love to get your input on how the ARISSat-1 project has gone, and what you’d like to see in the next satellite. Please fill it out at:  https://www.surveymonkey.com/s/arissat1-operation.

Next week, I’ll conclude this limited-series blog by examining the survey results and sharing our early plans for ARISSat-2.

-Steve Bible (73 DE N7HPR)

ARISSat-1 Official Web Site

The Radio Amateur Satellite Corporation

Read the earlier Chips in Space blog posts, here.