History of CubeSats, Chapter Two: First Cubesats

Introduction

Cubesats (or nanosatellites) represent an important chapter  in the history of New Space that may have been eclipsed by more glamorous stories of SpaceX, Rocket Lab or other players in launch industry. Nevertheless, emergence of simpler and cheaper satellite designs allowed smaller teams with smaller budgets to participate in space exploration. Notably, the first cubesats were launched a year before the flight of SpaceShipOne in October 2004, the first major event of New Space epoch.

First missions

Original cubesat specifications were published in year 2000 by Space System Development Lab of Stanford University. But the first real cubesats were launched on June 30, 2003 on a Rokot launch vehicle (a converted ICBM) as a secondary payloads, while MOST, a Canadian space telescope was one of the primary ones. They all were deployed into relatively high-altitude circular orbits with altitude over 800 kilometers and therefore still in orbit as of 2020. The missions and fates of all those satellites were very different and illustrative of both capabilities and limitations of the early cubesats. Let’s have a look at each of those missions in more details, starting with less fortunate ones:

  • CANX-1 was a 1U cubesat designed by University of Toronto, Canada. It was rather sophisticated for an early one, having an imaging camera, GPS receiver and proper attitude control and communication subsystems. Sadly, it never came alive after deployment and no signal was ever received from it. However it was not the last cubesat from University of Toronto Institute for Aerospace Studies and their later cubesat missions, starting with CANX-2, enjoyed more success. 
CANX-1 (Image credit: UTIAS-SFL, UoT)
  • The next in the list of less-than-fortunate ones was DTUSAT cubesat, another 1U one from Technical University of Denmark. Its primary mission was a deployment of electrodynamic tether and the secondary mission was Earth observation, meaning it had an imaging camera. It could be a pretty interesting mission, but again the satellite was dead after deployment, with no signal ever received from them. 
DTUSAT (Image credit: DTU)
  • The fate of AAUSAT-1, another Danish 1U cubesat from University of Aalborg was somewhat more fortunate. Its payload included an imaging camera as well. It became alive after launch and some radio signals were received from it. However, there were some problems with communications subsystem and those signals were very weak. Not much useful data were extracted on the ground. It was able to operate for two and a half months before its battery degraded. Still, it was a major step forward for cubesats in general.
AAU Sat (Image credit: AAU)
  • QuakeSat from already mentioned Stanford Space System Development Lab was  a mission to detect Extremely Low Frequency electromagnetic waves for potential earthquake prediction. It was a considerably larger cubesat, in 3U form-factor, that is 30x10x10 centimeters. Its mission was a lot more successful than of previously mentioned ones. The satellite operated for a year and half, producing valuable scientific results (short-duration ELF emissions were indeed detected, but reliable monitoring of these events requires funding beyond the scope of a single satellite mission). Here is another interesting fact about it: the RF transmitting power of this satellite was approximately 1 Watt, same as the transmitting power of the first satellite launched ever, Sputnik-1, back in 1957.
QuakeSat (Image credit: QuakeSat collaboration)
  • Next came two missions from Japanese universities. The first one to describe was named CUTE-1. It was designed by Tokyo Institute of Technology and its mission was testing transmission protocols for the space-to-ground communications. As with Quakesat before, this mission was also quite successful. It was fully operational at least until 2012, a very long time, considering the average cubesat lifetime is around two years. What is even more impressive is that CUTE-1 is still transmitting telemetry data, after almost 17 years of operations! 
CUTE-I (Image credit: TITech)

But another mission from Japanese team, 1U cubesat XI-IV has demonstrated even more impressive results. It was designed and built by University of Tokyo and had the primary mission of Earth Observation, meaning it had an imaging camera on board. And it was fully operational as late as June 2019, still able to produce the image with its CMOS camera and transmit it to the ground. Not bad for being also one of the first cubesats to reach orbit! Maybe we should learn a thing or two about satellite design from Japan.

XI-IV (Image credit: ISSL)

And here is the image gallery from XI-IV. You can see gradual deterioration of camera instrument, but the images are still legible enough to see Earth’ cloud cover.

Gallery of XI-IV images through 16 years of operations (The University of Tokyo)

References

  1. University of Toronto UTIAS-SFL Home Page
  2. Gunter’s Space Program Page
  3. Earth Observation Portal Directory
  4. On-orbit Operation Results of the World’s First CubeSat XI-IV – Lessons Learned from Its Successful 15-years Space Flight. Ryu Funase, Satoshi Ikari, Ryo Suzumoto, et al. University of Tokyo, 2019. SSC19-WKIII-09.

Sign up for updates on our own cubesat mission, NOVA! 

History of CubeSats, Chapter One: What Is a CubeSat?

We begin a new series of blog posts by our team members, explaining some of the concepts behind our business model and technology.

Cubesats are a classification of small satellites that are measured in a volumetric called a U, This U is a cube of dimensions 10cm x 10cm x 10cm (hence the term cubesat) and a satellite can be built of a set number of U’s. Such as a 1U communications node, a 3U earth observation platform or a larger 12U space telescope.

To understand how the cubesat concept evolved we need to understand the traditional design philosophy of satellites that has only changed in the last decade. Back when the first satellite was launched in 1957 we were still in an era of analogue electronics where you would require a single vacuum tube the size of your fist to have a single transistor in your circuit, compared to the latest processors today that have billions of them over a surface area equal to your fingernail. This means that for early satellites to have any form of capability they would need to be large in size for even basic radio communications.

Over the past decade consumer electronics have become small, cheap and most importantly: reliable. This means you can get high capability in a small package, which is important when you consider that per kilogram it would cost you up to 35,000 US dollars to get anything into orbit. This led to the development of the small satellite classification where a system that can fit in your hand can be sent into orbit and can be a communications platform, a device that can track forest fires or even a development platform where new technology can be tested in space at a reduced cost. Such as our mission NOVA.

The big advantages that cubesats (and by definition small satellites) bring to the table is cost to market, for previous missions you would have to use space grade equipment which is traditionally high cost and size and following that chain would lead to a larger satellite that would require a dedicated launch, again leading to higher costs. In a smaller size using off the shelf components costs can be saved, and multiple cubesats can be carried in a single launcher under a rideshare programme which further reduces costs.

Due to the lower capability of cubesats compared to the larger projects led by the international space agencies they are used heavily in commercial applications, this means that they operate in low earth orbit (LEO) where the majority of earth observation and communication satellites are based, although LEO is classed as any attitude below 2000km this tends to be more in the 300km ballpark. Small satellites are seldom used in higher orbits such as geostationary orbit (GSO) due to the cost of a dedicated heavy launcher that can send larger payloads to such altitude in addition to these higher orbits being more restricted due to their unique properties.

Mark Perkins

Sign up here for updates on our cubesat mission!

Our Thoughts On Recent Events

It is hard to ignore the humanity’s ongoing battle with the coronavirus pandemic, but we wanted to express our opinion in a balanced view, without falling victim to either underreaction or overreaction.  The overall situation is indeed serious and requires trust of recommendations from medical authorities, even if they appear contradictive and inconclusive sometimes.  Why? Because despite their personal flaws and incomplete knowledge  – they are still domain experts and are best equipped to solve this problem.

The second major point we want to stress – keep doing what you are doing, despite unfavourable circumstances. Adapt to the changing conditions and act accordingly to reduce the health risks, but don’t stop pursuing your goals and dreams. Even if you project may be unrelated to the current struggles of our world, it will matter in the long run, after the current storm will pass. If your business can survive in the worst of the times, it will grow a lot more in the times of plenty. 

With all the best wishes,

Exodus Orbitals team

Press Release – Another Client MoU Signed!

We are pleased to announce that we have signed another Memorandum of Understanding.

KP Labs intend to use our “satellite-as-a-service” solution to assist the development of their own on-board computer software; mission architects and engineers will be able to utilise it to create software for complex missions with the building blocks that KP Labs provides. These building blocks not only support rapid software development with ready-to-use features (like logging, scheduling, testing, communication), easy to set up hardware, an in-the-loop testing environment and/or software simulator environment, it is also an easy way of creating custom drivers and components for custom hardware.

About KP Labs

KP Labs is an innovative NewSpace company based in Poland. Their mission is to accelerate space exploration through the advancement of autonomous spacecraft operations, and robotic technology. KP labs expertise includes, but is not limited to, flight software, hyperspectral imaging instruments, AI algorithms, and high-efficiency Leopard processing units enabling on-board data processing. For more information, visit https://www.kplabs.pl/en/

About Exodus Orbitals

Exodus Orbitals is a British-Canadian space startup with the mission of making space exploration accessible for everyone through the development of a “satellite-as-a-service” software hosting platform in space. Our solution is based onsoftware-defined satellite technology that is being developed in collaboration with the European Space Agency. For more information, visit https://www.exodusorbitals.com

SPLICE: The Programming Language for Extraterrestrial Applications

Introduction 

As previously discussed, Java, C, and C++ are already perfectly capable tools for writing aerospace-grade software, while Rust programming language is an interesting new candidate that can combine the advantages of the previous generation of programming tools while discarding their drawbacks. However, if one wants to create space-based software development platform for a wider audience than ever before, one needs a solution that combines both ease of use with sufficient robustness for mission-critical applications in a demanding environment. Given below is the summary of requirements for such a programming language and proposed implementation for this requirement set, which will be tested on-board ESA OPS-SAT mission: https://www.esa.int/Enabling_Support/Operations/OPS-SAT

Requirements

  • Suitable for real-time applications. A typical mission for the satellite in space may consist of the performing a set of imaging observations of the ground below, with specific set for exposure values and wavelength filters selection. It needs to precisely timed or otherwise made conditional on other mission parameters (satellite orbital position and attitude orientation) to be performed successfully. 
  • RobustnessReality of space environment often interferes with the above plans: a satellite may be in dangerously low power state, satellite camera may face into the wrong direction or satellite onboard computer can tripped into reboot by a stray particle. Satellite hardware resources can be limited and not every downlink session will allow mission data to be downloaded. Therefore, its runtime environment has to be smart when it comes of task execution and storage of results and data.
  • Data-centricWhen editing and transferring instrument data and telemetry parameters to and from different satellite subsystems and uplink/downlink channels, one need good tools for aggregation, abstraction and marshaling of data, from individual bits to multi-megabyte imagery data. Any satellite instrument or component is expected to have some parameters or variables that can be either read and written to (like imaging camera exposure) or only read from (temperature sensors, very commonly). It would be useful to represent this difference in their declaration syntax and also check the validity of operations done upon them before the execution
  • Portability. The cost of software development for satellite missions comes from the need to qualify the software in the space, that is to run under realistic scenarios onboard the real satellite in space environment conditions. Therefore, it makes sense to compile source code not to target platform directly, but to some intermediate representation that be reused on multiple satellite hardware platforms, following the original Java “write once, run everywhere” promise. 
  • Simplicity. Finally, the last aspect of proposed specification of language is about not what to include into its feature set, but what to exclude from it. Available development tools should allow the developers to interact with the most interesting parts of the satellite – its instruments and instrument-generated data while offloading all the work necessary for satellite survival, such as power management as well as specifics of real-time systems outside of user scope as much as possible. 

Core Design Concepts

Space Programming Language Interpreter & Command Environment or SPLICE is a domain- specific programming language that enables development of software applications tailored for the conditions of space environment. It is explicit at what should be done but does not specify how execution of the program should be done, leaving that to execution runtime. 

Its major programming constructs are tasks and queues, inspired by the real-time operating systems like VxWorks or FreeRTOS that are often used as execution platforms for satellite mission software. Note that other elements of real-time systems, like interrupts or priorities are not exposed directly to users and are managed implicitly, within the language runtime, to reduce the complexity of software development for the users.

Tasks are lists of actions, that are specified to be executed either at given intervals or on certain conditions, specified by the following qualities:

  • How often they are run, either once only or within intervals between repeated execution defined in time range (1 second, 1 minute or 1 hour), only once or as fast as the task scheduler allows. 
  • When they are triggered to run – either unconditionally after fixed time intervals or conditionally bound by external (measured environment parameter value) or internal state (a successful execution of prerequisite task). 
  • What exactly are they doing – command the instruments or perform necessary calculations with the data values received.

Task lifetime is described through a following diagram:

Queues represent the major building I/O block, such instrument command queues, uplink or downlink channels or persistent/temporary data storage, specified by the following:

  • Interface description of the source or the destination of the data flow, specifying property type, command or telecommunication data packet format.
  • Read or write availability, as some queues, for example connected to telemetry sensors can only provide read-only functionality, and some such as ones of communication subsystem can offer both read and write functions.
  • Queues can be either persistent, saving their intermediate state to the persistent storage (such underlying file location) or ephemeral, discarding it between the execution runs.
  • As both ephemeral and persistent memory is a finite resource, queues also need to define maximum number of data elements stored internally and shedding behaviour – what to do when amount of data being written into the queue exceeds its internal storage capabilities. Shedding behaviour can be defined as “newest element gets discarded first” or “oldest element gets discarded first”, depending on the operational needs. 

Multiple tasks can be grouped into groups and queues into instruments, for better program structure and user convenience. To ensure deterministic behaviour, loops and control flow constructs are provided only at the task level, simplifying the logic of program execution.

4. SPLICE Syntax Examples

Let’s now have a look at the proposed syntax through some SPLICE program examples. Most of the syntax examples below should be self-explanatory for any software developer exposed to the commonly used programming languages. Most of syntax constructs are borrowed from C-derived languages, including Python, Rust and C++.

/* Comments are the same as in C-derived languages, both for single and multiline types */

/* Types declaration use Rust-like syntax */

//32-bit signed integer
var an_integer:i32

//8-bit unsigned integer
var unsigned_int:u8;
 
//single-precision float
var a_float:f32;    

/* variables can be initialized at declaration, for cardinal types initialization is optional though */
var initialized_integer:i32 = 0; 

/* strings are always allocated statically and has to be always initialized at declaration */
var a_string:string=”a string value”; 
 
/* constants declaration examples */
 
//floating point example
const PI:f32 = 3.14;

//integer constant
const TASK_OK:i32 = 0;

//and a string one
const INFO:string = “a string constant”;

/* Custom type declarations */

//complex types can be assembled from built-in ones
type TPacket {
      header: u32;
      data_a: f32;
      data_b: f32;
      data_c: f32;
}
 
//type declarations can use nested complex types 
type TCommand {
      uid: i32;
      command: string;
      data: TPacket;
}

//variables of complex types can be declared as well
var packet:TPacket;

// ..and initialized, when necessary or desired so
// but for some of the fields initialization can be optional
var packet:TCommand = {
      uid:0,
      command: ”Command string”,
      data: {
            header:0,
            data_a:3.4,
            data_b:-0.5,
      }
};
 
// constants can be of custom type as well
const TEST_PACKET:TPacket = {
      header:0, data_a:0.0, data_b: 0.0, data_c:0.0
}

/* Instrument declarations – semantically they are interfaces */
 
//a simple instrument example – GPS receiver
inst gps 
{
      //”prop” keyword indicates read-only value
      prop lat:f32;
      prop lon:f32;
      prop alt:f32;
      //can be turned on/off from user programs
      var powered:bool;
} 

/* UHF transceiver instrument example. Note the use of queues, as being in a ground station view is required to send or receive any data */
inst uhf_comms
{
      //NOT safe to turn it off
      prop powered:bool;      
      queue downlink {
            size: 100;
            type: TPacket;
            // shedding modifer, as explained above
            shed: “last”;
            // access modifier: “push” is write-only
            accs: push;
      }
      queue uplink {
            size: 100;
            type: TPacket;
            //access modifier: “pull” is read-only
            accs: pull;     
      }
}
 
/* another example – taken from actual satellite mission */
inst camera 
{
      var exposure:f32;
      var gainR:f32; 
      var gainB:f32; 
      var gainG:f32;
      //can be turned on or off safely
      var powered:bool;
      prop imageCount:u32;
      queue commands
      {
            size: 10;
            type: TCommand;
            accs: push; 
            shed: “last”; 
       }
}
/* task and groups declarations examples: in the most basic case, a list of actions to be executed under certain conditions and with specific execution frequency. groups are collections of tasks, where all tasks has visibility of each other execution results and local data in read-only mode*/ 
group task_group_1  
{
       task task_1 { 
              //tasks can have their own variables and constants
              data {
                     var lat:f32=32.21;
                     var lon:f32=120.1;
                     const ADCS_MODE_NADIR = 5;
                     var target_mode: TADCSMode = {
                            command:”set_mode”,
                            mode_id: ADCS_MODE_NADIR,               
                            duration: 300s
                     } 
              }   
              
              /* frequency of execution, can be "once",
              “always” or time value in seconds */ 
              freq: “once”;    
              
              /* prerequisite section, statements below 
              has to be true to allow execution */ 
              preq {
                     gps.lat == lat;
                     gps.long == lon;
              }   

              /* executive section - the actual actions 
              and logic of the task. Task execution result is 
              saved after task execution and updated after each 
              run, so it can be used for other tasks as 
              prerequisite */
              exec {
                    //pushing a command to subsystem queue
                    adcs.command.push(target_mode);                              
                    return TASK_OK;
              } 
       }  
 
       /* one task can read another task data (from the 
       same group), but not write to. Variables, constants 
       or queues can be used for data transfer between tasks */       
       task task_2 { 
              data {
                const NX:i32=task_1.ADCS_MODE_NADIR;
                var gainR:f32=1.0; 
                var gainB:f32=0.5;
                var gainG:f32=0.5; 
                var exp:f32=0.1; 
                var cam_commd:TCommand; 
              }
              
              /* time literals have prefix as “s”,”m”,”h” and so        
              on, depending on mission needs */ 
              freq: 60s;    
              
              /* task execution result can be a prerequisite too,        
              in addition to conditional expression */           
              preq {
                     adcs.mode == NX;                  
                     task_1.result == TASK_OK;
              }
              
              /* There can be no loops or conditional 
              expressions in the execution section – just a list
              of statements */
              exec {
                     cam_commd.uid =1;              
                     cam_commd.command = “RAW”;                
                     cam_commd.data_a = gainR;                                   
                     cam_commd.data_b = gainB;
                     cam_commd.data_c = gainG;   
                     
                     /* instruments can be controlled through 
                     command queues or by directly editing their                   
                     parameters */
                     camera.exposure =0.2;                    
                     camera.command.push(cam_commd);
                     
                     /* task context, including local data is 
                     saved between runs, allowing complex                      
                     execution logic */
                     gainR = gainR + 1.0; 
                     gainB = gainB + 0.5; 
                     gainG = gainG + 0.1;
                     return TASK_OK;
                  } 
         } 
}  

Progress To Date

At the moment, the current implementation of SPLICE only exists as intermediate representation in VM bytecode and simple assembly language, with most of high-level syntax is not yet fully defined and many planned features still undergoing internal discussion. 

Undoubtedly, as we gain experience through orbital operations later in 2020 and learn more from both successes and mistakes, both specifications and implementation will evolve and improve, adding more features to allow more interesting applications. Going forward into our next satellite mission, we plan to implement a fully featured software development kit, including high-level compiler and satellite ground simulator as well as allowing deployment of user programs onboard our own crowd-flyable mission – NOVA, to be launched later this year. Keep in touch with us on social media  to follow our progress and send us feedback and comments!