Benoit Chamot (Innovative Solutions in Space): CubeSat, a crash course

Benoit Chamot, Technical Sales Engineer at ISIS, explained how they have made it cheaper and easier to launch satellites, not just by designing the CubeSat platform, which simplifies life for both satellite builders and launch providers, but by relationship building and launch capacity brokerage to bridge the gap between small amateurs and large professionals.

Transcript

Good afternoon everyone! I’m probably the least knowledgeable person about blockchain in the room, so I on purpose left any blockchain comments and reflection out of my presentation. My goal today is to cover CubeSats: what they are, what they can do, what we do with them, what we built. The only blockchain reference was my working title was ICO, as in Initial CubeSat Offering — that’s going to be the only blockchain joke, I promise! [laughter]

Who are we? We are ISIS, the other one. You probably know our… [laughter] our after-sales department in Syria; we recently closed the Baghdad office. [laughter] Innovative Solutions in Space, we’ve been around since 2006, we’re based in the Netherlands, between The Hague and Rotterdam. The company started as a spinoff of the Delfi-C3 satellite project from the Technical University of Delft. Five students worked on this project, launched the satellite, decided they did a good job, building a satellite that is still working up to this day, 10 years in orbit — they started the company a bit before the satellite was launched — 10 years in orbit and still working, and so they decided that they wanted to continue in this business and sell subsystems to all the universities that are also building satellites. That’s how the business started: building structures, communications systems, onboard computers for all the universities to use.

Then they also realised that it was difficult to launch satellites, and that getting in contact with the launch providers and putting your stuff on rockets was not easy. There are technical challenges, but it’s also a lot of relationship building that you have to do, understanding the launch world. Also, when they started in this business CubeSats were really new, these small satellites, so approaching launch providers to be able to get your satellite on a rocket was difficult, so we started as one of the first launch brokers for CubeSat. Basically, what we do is we buy extra capacities on rockets next to big satellites, and then we sell that to our customers. There’s 260 satellites that we’ve launched; we haven’t built all of them, but they are satellites that we’ve launched through this launch brokering service. We’ve done over 13 launch campaigns all around the world, we a bunch of upcoming campaigns this year, and many opportunities in the future as well.

12 years in we now have about 90 employees. Most of us are in Delft, in the Netherlands, but we also have a small office in South Africa, and we are also interested in opening more offices around the world. I’ll explain the business as I go through the presentation as well, but we do build satellites, including the subsystems, we also do system integration. We launched them, as I said, and we also operate them from our ground station in Delft. The satellites that we’re involved with are typically between 1 to 25 kilograms, so really, really small.

I wasn’t exactly sure about the level of knowledge of the audience about satellites. I’ll go through a few different concepts that we deal with, and maybe they are very, very obvious — there’s coffee outside, so feel free to get out for the next few slides, if this is too obvious and too easy. Our main role as a company and what we do is we are a turnkey mission provider of CubeSat in low Earth orbit, and I will just go through these different concepts, starting with low Earth orbit.

Most of the satellites that people usually think of are big, geostationary communication satellites. Geo is geostationary orbit, at an altitude where the period of the orbit is roughly 24 hours. The satellite will go around its orbit, at the same rate that the Earth is rotating around itself, always staying over the same point.

That’s not the orbit we’re in. We are in LEO, which is low Earth orbit, where you typically have the ISS, you have Earth observation satellites that are there, and most of the CubeSats that we’ve launched and that are operating there. It takes much less energy to go to LEO than to go to GEO or even beyond.

We’ve been to the Moon last month. We’ve built another complete satellite, there are subsystems that we have built and that we’ve mounted on there on the Chinese probe that has been launched to the Moon last month, and so we are doing science operations from that location. those are the same subsystems that we have in our CubeSats, proving that for now we are in low Earth orbit, but we have much bigger ambitions than that, and the Moon is one of them. That was for the low Earth orbit.

What do we mean by turnkey mission? The satellite of course is only one part of the overall system, of the mission, that’s what we also call the space segment. But you also have the ground segment, you need to have ground stations, antennae and radio, to actually receive the data from the satellite and communicate with it, so the operation side is also linked to that. You need to get the satellite to orbit as well, you have the launch segment. It’s big in this picture not only because I had to fit the rocket, but also because a big chunk of your budget will go into that, and once you get all that money from the VC, that’s typically where you will have to invest it as well.

There’s other elements to the mission as well, like training and support. A lot of these satellites are used for e use a lot of these satellites for knowledge transfer, capacity building for countries or entities that don’t have a lot of experience with space, and we can also train them and support them, as part of this mission. Then all the new development, so all of the things specific to the mission or new technology that we have to develop, to enable a certain mission, and we can do all of that. In some cases we will just provide parts of these satellites, the subsystems only — how the company started — in some cases we will just provide the launch, and we also have customers coming to us with a need for data or a certain service or an instrument that they would like to fly, and then they don’t want to deal with any of the other satellite business, and then we can do that for them. We can also do what we call in-orbit delivery: we build a satellite, we launch it, we commission it, so we make sure that it’s working properly in orbit, and then we hand it over to the customer for operation, or we continue with the operations ourselves. That’s what we mean by turnkey.

When it comes to the satellite itself, I’ll typically talk about bus or platform on the one hand and payload on the other. The payload is the reason why you launch your satellite: it’s your instrument, it’s your camera, your sensors, your radio system, if you have a communications satellite — whatever reason you launch the satellite for, what you want to have in space. And the bus and the platform is what’s going to support the payload: power management and data management on the satellite, communication with the ground for housekeeping data and these kind of things, all the boring stuff that can be the same from one mission the next but that you need in order to support the payload in orbit, and that’s the part that we are focusing on. We have developed a bunch of payloads, we can also have access to payloads in order to provide the right data to our customers, but our core business is really in the bus and the platform, and we will work with partners for the payload.

So that’s the turnkey mission part and the low Earth orbit part covered, so now I can finally focus on the CubeSat and on this crash course.

Here’s one for instance, very small satellites. This one is a satellite that we’ve launched last year, it was a technology demonstration. The dimension of this system 30x10x10 centimetres, the size of a bottle of milk, very small, and the mass was around four kilograms. That’s one of the many sizes that we can have as far as CubeSats are concerned.

The whole family that we are working with we talk in terms of U or units. One unit is 10x10x10 centimetres, a small cube, with a mass typically between one and two kilograms, and that’s the origin of the CubeSats. That’s something that was developed by Cal Poly at Stanford in the US in the late 90s, and the idea was to develop a new standard of satellite, to force the students to think inside the box for once, and force them to comply to certain standards and certain constraints, in order to facilitate the development and then the launch, because all the interfaces, the general design of it and then the interfaces to the launch vehicle will be standardised. So it started as this really, really small satellite, and smaller is also cheaper to launch. But as the concept developed and people wanted to do more interesting things with them, they also realised that this was very constraining.

So we’ve seen the evolution of spacecraft, the PC revolution, from the very big satellites down to the smaller and smaller and smaller ones, and now we’re also seeing the other effect. Something that I usually say is the PCs started very big, with a big mainframe that takes up a whole room and got smaller and smaller, up to the point where we have small laptops and phones. But if you look at the phones themselves, cell phones started really small, and now they’re getting bigger and bigger and bigger, because you want a bigger screen. We are seeing something similar with CubeSats: they started at this one unit, 10x10x10 centimetres and around one kilogram, but then they have also grown during the years. Most of the satellites that we are building are the ones that are in the middle of this slide, 3Us and 6Us, and we are working with bigger satellites as well.

The advantage is, as you can see, that’s a 3U CubeSat with deployable solar panels. Power is a big issue, you need to generate power for your payload, for your instrument. Deploying more complex solar panels is one way to do it, having a satellite that is a bit bigger, with cells that are on the satellite is another way to do it for instance, you also get more volume inside. So CubeSats are not only these really, really small satellites; there is a wide range, there is a whole family.

A question I get a lot is how do you launch them? We use what we call deployers or dispensers, you have an example here, big blue blocks. The principle is very simple: you can see the springs inside, you have a plate and then a spring behind it, and the picture on the left shows that you slide the CubeSat inside this dispenser, you close the door, bolt that on the rocket, there’s a big boom in the right direction, and then once in orbit you open the door and the spring will simply push the satellite outside of the box and it’s in orbit. The nice thing about that is that the only thing that we deliver to a launch provider is a closed box, they don’t have to care about what’s inside the box. There are a few legal details, but as far as the technical issues are concerned, what’s in the box is the responsibility of the satellite builder, the launch provider just sees a blue box with a certain mass, and that’s what’s mounted on the rocket and that’s what they see.

Whether it’s a telecommunications satellite built by a private company inside, whether it’s something very new that was bolted together by a bunch of students from whatever universities, to the launch provider it’s technically the same. That’s the advantage we have, and that’s also how we can have these good relationships with a launch provider and launch so many of these satellites, because we have simplified the interfaces on either side: to the customer, to the satellite provider and to the launch provider. That’s how we put them in orbit.

Another thing I want to talk about is the philosophy behind CubeSats. The nice thing with this system is that they can be very modular. You have seen the different sizes, and the way we build them is by using the same building blocks, whether we’re talking about a small satellite or a big one. We get more performance out of it, we get more power, more processing power, we have more volume, but the general idea is the same. Whether you’re talking about really small, 1U CubeSats or the much bigger ones, we will typically have the same kind of onboard computers, you can see our onboard computer on the picture, and then the idea is to have these Lego blocks. We’ll have the onboard computer that is connected to the power system and to the other systems on the satellite, and we can expand them to expand the performance, but the blocks themselves stay the same. We can also mass produce these systems, so we also gain on cost on the one hand.

The other way, the other difference in the philosophy between these small satellites, between CubeSats and the larger satellites is also the type of components that we use and the level of risk that we take. We typically use off-the-shelf electronics components; we don’t use red hot components. We do a bit of screening of the electronic components that we use, but not as much as is the norm in the space industry, and the advantage is that we have access to the components much quicker than what the traditional space organisations do, and we can also reduce the cost like this. Because red hot components in space, proven components or qualified components are more expensive than off-the-shelf electronics. So we can reuse the same subsystems, no matter what the size of the satellite is, we typically don’t have custom-built subsystems per mission, and we use commercial, off-the-shelf components, and we reduce the cost like this.

Now comes the part in the presentation where I disappoint you. Because we hear all these great things about CubeSats and how small they are and how fast they are and how they are going to completely change the world and do things. Like most things in life, this comes at a certain cost, and they do have limitations. One of them is power generation. We have so many people coming to us with these great ideas and this great payload and all this processing power that they need and that they would like to fit in the CubeSat because they’ve heard that they’re cheap. We discussed going around laws before, but there are some laws that we can’t go around, and those are the laws of physics, and if you want to have power in your satellite, then you will have to put solar cells on them. You have an example here of a 6U satellite that we’re working on with deployable solar panels: you will generate roughly 100 Watts peak power, that’s when the cells are pointing directly at the Sun.

Of course in low Earth orbit you also have a period of eclipse, you have the Earth which is in-between your satellite and the Sun, when you don’t generate any power and you have to rely on your battery, and then depending on how the solar panels are pointed at the Sun you will generate more or less power. On average, you actually have 30–60 Watts directly available from the solar panels, so you have to rely on your batteries then, if you need to have more power during that amount of time, so you will deplete your battery that you will then have to recharge as well, so that’s one of the limitations. The other one is the obvious one: that’s the volume that you have available. So they can do a lot of things, but it comes at a cost. Just because they are smaller and cheaper doesn’t mean they can do the same things that some of the big satellites can do, because there are things that we can’t change.

Another big limitation that is probably relevant to you as well is the data rate that you can have. That’s the ground station that we have in Delft, it operates on a UHF and VHF for uplink and downlink, that’s what we use to send simple comments to the satellite and receive the housekeeping data, and then we have a dish as well for S-band, so we also have a version with a larger disk for better performance for slightly higher data rate, and we’re working on the next band station as well. The typical rates that you get is around 10 kilobits per second for UHF, 10 megabits per second for S-band, and 100 megabits per second for X-band, but that’s basically what you will get. And the satellite is moving pretty fast: in LEO you have an orbital period around 90 minutes, so the satellite is going fast, it is not going to stay over a single point for very long, and the orbit relative to the Earth is also moving, because the Earth is spinning. You typically have in LEO six passes a day, three during the day and three during the night, and on average about seven minutes each, that’s it. That’s not a lot of time that you have with your satellite, and the data rates are still pretty low.

Of course that’s just for one ground station: if you have a ground station network, and that’s one way to improve the situation, then you can increase the data volume that you get. But this is 100 megabits per second, that’s pretty much the state of the art now. There are systems, some of them have been launched, prototypes have been used that can do much more. But that’s basically the situation right now, and that’s mostly due to the power that you have available on board to transform into RF power, but that’s also due to the size of the satellite, because you can only have small antennas, so you can’t have rates that are really high, and that’s something that you will have to take into account when looking at these CubeSats. Yes, they have benefits, they have advantages, but it also comes at a cost and that needs to be taken into account.

I’ll talk about the good aspects again, and one of them is the short development time. That’s due to two reasons: the first one is the fact that we use off-the-shelf components, so we can have access to them relatively quickly, and the other one is the level of risk that we can take. And then these standardised building blocks, meaning that if we build an Earth observation satellite or a communications satellite or another type, the platform, the bus is going to be pretty much the same every time, so we also spend less time designing and refining, and we can reuse not only off-the-shelf components but also designs that are almost off-the-shelf as well. And the risk that we take is not only in the selection of the components but also in the level of testing that we are going to do, and that all depends on the customer and on the amount of risk that they want to take. If we work with the European Space Agency, we are typically going to spend much more time testing the satellite and refining it, and we know how to design satellites like this. Of course, it’s not at the same price and it doesn’t take the same amount of time.

The typical timeline, from the kick-off meeting, signing the contract and all the way to launch is typically 12 to 18 months. We’ve been much, much faster than that once, and ideally we don’t want to do it again, because it’s obviously very stressful, but the main reason is the amount of risk that we took. The two satellites that you can see on the picture here are the two precursors for the QB50 constellation, which was a research project funded by the European Commission. The idea was to launch 50 satellites, hence the name, but in the end I think only about 38 these satellites were launched, all built by different universities, different entities, and they are working together to take measurements in the upper atmosphere.

The European Commission wanted to de-risk the project a bit, test the payload and test some of the components used, so we built those two satellites. From kick-off to launch, we had four months to build two satellites, in which we had a completely new onboard computer, a completely new revision of the radio system that we were using, two payloads that had never worked before. I showed you the blue box, the deployer that we used for the launch: it was the maiden flight for this version of it, which was much bigger and completely new. Because we had not only these satellites but other customers on this rocket, we also had five of these dispensers, carrying payloads from paid customers inside, and we’ve realised that the launch vehicle didn’t

have enough data and power interfaces to interface with five boxes, so we also had to develop a sequencer on the spot to be able to receive the signal from the rocket and then distribute that to all the deployers. Like I said, we can do it, we loved doing it, but we’d rather take a slightly more conservative approach in general, not only for us but also because, as you can imagine, although it was supposed to be a de-risking mission, we actually took quite a lot of risk.

One of the additional things that we did during this mission, because of the time constraint, was both satellites were actually launched with very limited software on board, and then we had to spend our time to develop a way to reprogram the onboard computers in orbit, and we’ve done that multiple times since, and so that’s also something that we are able to do now, and we learned a lot from this mission. That allowed our software engineers to focus only on the core functionalities first, and then this boot loader, this way of updating the firmware of the satellite in orbit. Then they had much more time, between the time when we delivered the satellite for launch and when it was actually launched, to continue the software development, continue testing, and then upload this software afterwards.

Question: did it work?

They did work, yes. One of them is still in operation and fully functional. The other one accomplished all the mission objectives, and then we had one failure on board, one of the radios stopped working, and we think it’s due to EMIs, electromagnetic interferences, between one of the payloads and the radio system. And that’s a great question, because that’s exactly what you get when you don’t test enough, that’s typically the level of risk that you take. One is still working, the other one worked for the mission that was planned, and then we had this one edge case where the satellite failed.

So, short development time is the first big benefit, and the second big benefit is lower costs, again because of these standard components and standard building blocks. That also means that for the price of one big satellite, so that’s an Iridium NEXT satellite that operates in LEO, you can launch a lot of these CubeSats, and that’s including not only the cost of the satellite but also of the launch. And then you can use them together in a constellation with many additional benefits. In terms of revisit times, you have more satellites going over the same spot over the Earth, so you also increase your coverage. Scalability, meaning that you can launch a few satellites, you have a small constellation giving you a certain level of performance, and you can add satellites to this and you have the same basic service, but you improve the accuracy that you get of the coverage, and then you generate more revenue as you add satellites.

Failure tolerance, what we call external redundancy. We typically have limited levels of redundancy inside the satellite, but then if you have an exact same satellite just next to it, if one fails then you still have the other one. And low data latency, because if you have the constellation in orbit and the ground station network, you can also download data more often from the satellite and receive data more often. You can also use intersatellite link and the satellites will communicate with each other, and then we transmit the data until there is one satellite that is in view of a ground station.

I’ll go quickly over a few of the applications, what they can do. We’ve heard about many of these applications, so I’ll just talk about two specific examples. One is Planet, formally known as Planet Labs. I don’t take any credit for the satellites themselves, we don’t build them, but we do launch them. They operate around 300 satellites now, and the mission objective is to take a picture of the whole Earth every day, so they have all these satellites going around, taking pictures of the Earth with very good resolution, and they were one of the very first VC-backed companies who actually launched their constellation.

The other one is two satellites, two 6Us that we are building now that we will launch in August for a company called Hiber in the Netherlands. They have a machine-to-machine system, their idea is to have a constellation of satellites listening to sensors on the ground, and one of the applications would be container tracking and asset tracking on the ground that can be used for agricultural improvement as well. It’s up to the end customer actually to decide what they want to do with this system and with the data, and we provide the satellite to them.

I’d be happy to hear your thoughts, how we can integrate blockchain into our system or help you launch your own mission — thank you!