 Ευχαριστούμε για το καλύτερο πρόγραμμα. My name is Piero Papadeas and I'm here to talk about UPSAT, UPSAT or UPSAT, however you pronounce it, that's the same thing. As with the previous talk, with Nikos I'm also from the Libre Space Foundation and for those of you that were not here or didn't have a chance to pass by our booth in the AW building, the Libre Space Foundation is a non-profit foundation established in Greece, but we have global operations and global volunteers and participation right now. And we're focusing on creating open source technologies in space. And that means pretty much everything that has to do with the ground segment and the space segment, so both sides of the space industry, if you might say. Specifically about UPSAT, our story starts back in 2012. That's before the Libre Space Foundation was actually born and at that point the European Commission was giving the go-ahead to a really aspiring and really audacious project which was, and still is, QB50. The QB50 project is an FP7 European Commission project, headlined by the von Karman Institute for Fluid Dynamics, which is based out of Belgium here. And the concept of the project was actually really interesting. There was a science mission which is to study as much as it can be done the thermosphere, previously not yet completely modellized and studied part of the atmosphere. In order to do that, create a swarm of satellites, so many satellites, initially 50 of them were planned, and equip them with similar sensors. There were three different kinds of sensors that the teams were given, and then let the teams, and that would be academic institutions, research groups, or any other non-profit and academic or research group that was out there, to design a CubeSat around the specific sensors. So there was a group of people on those institutions that initially created the QB50 project, that created and designed and funded the initial creation of the sensors, and then as a team you would apply to create a CubeSat, and you start building a CubeSat around this specific sensor and actually be part of the mission. There were many advances and advantages of being part of the QB50 program. One of them would be the slightly discounted price for actually launching your satellite in space, which is important, plus a bit of documentation around the verification and some work that it could have been done around it, so that you don't nearly duplicate yourself all the time. The reason why the duplication happened a lot was in the QB50 project as we are going to be seeing, and where we come in is basically in Greece, back in 2013, there were two different teams that applied for the QB50 program. Both of them got their own mission to start designing a CubeSat around that sensor, and one of them was the Patras University, and in contrast with everything else that most of the teams did on QB50, they didn't just go out and buy a commercial of the self components which are readily available right now in the market for CubeSats to build CubeSats. There are various different companies that actually create modules and subsystems of CubeSats, and you can just go in and buy them literally in ESOPs and start building and assembling your satellite. And in contrast to that, the University of Patras said, well, we're going to be designing everything from scratch, and that's, well, a bold move, first off, because they didn't have any previous experience on a space project, and also it's really kind of like reinventing parts of things that other people have been doing around. So at that point, the progress was happening slowly on the University, and there were some funding and managerial issues that actually didn't let the project evolve with the pace that they wanted to get involved. And what happened is that although they got the actual sensor, pretty much everything else except probably from the structural part was missing even some months before the launch of the satellite. So things were moving slow, things were changing. In a typical academic environment, unfortunately, people come and go, and especially for a project that spans multiple years, then you have that kind of drop off, and there was no easy retention due to that. So at that point, they contacted the Libre Space Foundation initially just for the ground station, because as you saw in the previous talk, or you may be familiar with, the Libre Space Foundation also runs the SATNOX project, it's a global network of ground stations. So the university team decided to reuse some of our SATNOX components in order to build up a ground station and get done with the telecommanding control and payload acquisition, data acquisition from the satellite. So initially, they reached out, like, okay, let's build a ground station, and then we asked them, okay, that's great, we can certainly do that and help you in the process. But then we started asking around, what's your encoding, what's your frequency, how is your command and control going to be working on, and what's the framing, what's the payloads and everything else that you have. And we were getting less and less answers around that, and less and less clarity around the specifics of the satellite, and it was obvious that the progress was really not as anticipated. So at that point, they actually came to that realization, and we entered into an agreement on us taking over pretty much the whole satellite, except the structural components and parts of the electrical and power system, co-funding the actual project and turning it into an open source project for the first time completely for the satellite. So when they reached out with the formal proposal around it, they said, well, you know, you have to do this and there is not really money around it, so it has to be funded also by you. And we said, okay, cool, I mean, the Libra Space Foundation did have some funds at that point, and we wanted to invest on open source and space, so let's go ahead and build it together with you. And we asked how much time do you have, when do you need to deliver the satellite? And they said six months, and we're like, okay, cool, let me take that back to the engineers and, you know, contact you about that. And at that point, we were thinking, you know, on one hand, six months space project, not really compatible. On the other hand, it was actually a really nice opportunity for us to be in and be in control of designing a CubeSat from scratch and actually doing it in an open source way for the first time. So the return of investment in terms of the community and the knowledge that we're going to be gaining might be worth it, although we entered the whole thing knowing that, well, there is a pretty significant chance that we might not, you know, be able to deliver things on time. So we said, yeah, yeah, six months, cool, yeah, let's do this. And like every good engineer does, we, you know, first day in the project, like we said, well, let's see what we can reuse and learn of things that are out there. And in a super engineering way, we just went on a search forum and said, well, open source satellite, open source CubeSat, you know, what is out there in terms of not even licensed open source things, as we will see this pretty much nothing. But also, you know, general documentation about the satellite itself, like best practices, not only the actual result but integration, building the satellite, verification, testing. You know, what can we learn about things that go in space. And interestingly, back in the day, if you search for open source satellites, four, three or four different projects came up and we were really excited about that. One of them we actually did know about. Back in 2013, that's the ArduSat project, and there have been two iterations of the ArduSat project. And ArduSat, as you can imagine, in a typical terminology, is an Arduino satellite, ArduSat. And we remember reading about it, like being super excited about it in our local Hiker space, that there's going to be an Arduino backed satellite out there. And we didn't really understand, you know, what this meant in terms of the actual satellite. I mean, yes, it's going to have an Arduino inside, but the rest of it, or is it going to be only Arduino? So for the first time, digging like really into, you know, what was happening, unfortunately what we realized is that only one module, like the payload itself that had multiple Arduino compatible cores was actually distributed open source. The rest of it was just closed source implementation of specific companies. So it was really a, you know, downer for us to see that this was not the case. So we said, well, let's move to the next thing that we found out on the web. And we saw this one, really promising, open source satellite initiative from Japan. There was a single person project, more or less. Super bright engineer slash artist that had this idea of let's democratize space and do that in a way that we can distribute things back to the people and not reinvent the wheel. And it all sounded really great. And we started searching into the code and we saw that there was not really any license around it. So that has been omitted on every different repository that we can find. And we couldn't even find the finalized actually versions of the repositories. So downer again. And the technology was like really behind. Like that's a reference design and think that was built around 2011 and 2012. And as you can imagine, the technology around microcontroller and other things has moved a lot and it moves a lot faster than that. So five and six years after that, we needed a more modernized approach to many things. So yeah. The next result and a common kind of feedback that we get whenever we say that UPiSat is an open source satellite. Many people say, well, AMSAT has been doing that for years. And it's true that the amateur radio space associations and those are amateur radio groups that are building radio amateur satellites. And that would be satellites that actually can be used for voice repeating or digital repeating of operators that are using those satellites around the world. Indeed, those have been built in a slightly open spirit. The problem with that is that first off, especially for AMSAT North America, they are governed by export regulations of US. And the ITAR regulations are pretty strict and you cannot get access to any documentation around them. Although within them and within the groups that they have, they could distribute things about the launches themselves and the satellites themselves. There is minimal things that you can actually publicly reuse, if any, and that has only been trying to change over the past year or so. And we've been working really close together with them. But there's also another problem which is many of the people and the projects that the AMSAT has been collaborated with in order to get the satellites in space have been actually defense oriented. Like the Department of Defense of the United States and other agencies around it. So information about many of the things like launches or even the actual Keplerian elements like the TLEs, like the orbital characteristics of AMSAT satellites are not freely distributed from the sources that we know. So yeah, looking into that, especially two years ago when we did that, like a year and a half ago when we did that, there was not many things in there. Then there were various examples of satellites that have done phenomenally good job on documenting the process of building a satellite. And one of them would be SwissCube from Switzerland that has been a super successful mission in terms of the time frame and how long it has been in space and how long it has worked and performed really well according to the original mission. But the documentation is outstanding in terms of learning material to understand the process of building a satellite, the pitfalls, best practices and things like that. But once again outdated and unfortunately not open source licensed. And of course they never go to code specifics and schematic and PCB layouts and those kind of specific things that you would need to rebuild a satellite. So the overall answer to the question, well, is there anything out there that we can directly and really quickly build upon and reuse? And the answer was not really, unfortunately. So that put a lot of pressure in the project itself and the people itself to really outdo ourselves and trying to document everything that we do and make sure that we are as open source as possible in terms of our licensing. But also our learnings and things that are not necessarily covered by license itself, software or hardware license. So as we said, like we started with a sensor itself. By the way, the sensor for those of you interested in that, the name of it is MNLP and that's a multi-needle Lagamo Arprobe and that measures plasma on the thermosphere. It's a setup with a bias, an electron emitter that actually helps you identify plasma on the sides. And that's the science part of it. So that's delivered to you as a black box and you can only interface with it. You have a state diagram which you know what's happening on the payload itself. And then you need to, through a serial UART interface, you know, command the payload to do a couple of different things. And most of the times when people think about the satellite itself, like the thing about the payload and what does it actually do, right? Like this is a mock-up of a satellite, by the way, which we have here, had for the previous talk and we have now. And while we had it on the booth over the two days here, many people came up and said, well, that's a satellite. It's an open source satellite. And the obvious, you know, the first question is, what does it do? Well, it does the science experiment, right? So that's pretty straightforward. But for us, it might be partially an excuse to build the satellite, like the science payload itself. And that's because most important for us would be to actually validate that things that we developed as open source projects that people can use and reuse and rebuild upon them are validated in space. That by itself is a mission for a CubeSat as it is. So that's equally important, if not more important for us. So starting, as you can see, space loves abbreviations and acronyms. So everything is like three to four letter codes. And we start with the science unit, the S-U-M-N-L-P on the left side. And then you work your way up the satellite having different components of the satellite itself. So the next stop would be the EPS. You see the three batteries, 18650, Li-ion batteries. And the EPS stands for the electrical power system. That's the power supply, basically. And that makes sure to charge the batteries from solar panels that you have all around or almost all around the satellite itself. And then you move upwards to the ADCS. And that's the attitude, determination and control system that understands where the satellite is, how the satellite is pointing and trying to correct that pointing of the satellite. We don't have the capability for this kind of satellite to actually course correct, like make corrections on our orbit. But what we can do is orient the satellite so that we can make sure that the camera that it had on board looked down on Earth and the antennas are pointing to the right direction and everything worked as it should work. Then we move to the OBC, that's the on-board computer, kind of like the brains of the satellite. That will be the central logging system, basically, and the one doing the experiment, like talking to the science unit. Then we have the IAC, you can see it's a lens with a camera. So IAC stands for Image Acquisition Component. It's just a camera, but you have to name it fancy if you are in space. So next up we move to the COM platform, or COM platform, which is the communications subsystem, making sure that there's communication down to Earth, down to our ground stations. And I'll go to details about COMs in a bit. Then we have the GPS unit, the GPS antenna and the antenna system with a deployable panel, basically, deployable part once it's in space. You can take it out here and look into that. So another component of the whole thing is the actual structure. That would be for aluminum rods and then the aluminum frames. Then the sides would be CFRPs, so carbon pre-pregnated panels, and those would be hosting basically on top of them the solar panels. So that would conclude the satellite design by itself, at least for the major components of it. And here we had to, when we started, try to categorize what's the different kinds of subsystems and things, and what should talk to what in terms of the subsystems and everything else, and not really having experience before, and not really being able to follow any specific directives about them. We had to really start from the simplest form of things that we could think of and then build quickly upon them. So you can see the major subsystems laid out. And all of them in their core, they're run by a microcontroller, in our case, that's STM32. And we have Cortex-M4s and Cortex-M0s. And some of them run freeR2OS so that the scheduling and services were easier to implement on them. And some others are just bare metal, only with the hardware abstraction layer, obviously, in them. So you can see that the major communications that are happening are not happening in a bus. That's actually a pitfall of the design and we are never going back to that in terms of satellite design. There should be a bus for various contingency and other reasons. But we were pretty confined in terms of the initial diagrams that were designed by some previous engineers that were working in the project. So some of the components were already bought, so we had to improvise how we're going to be adapting our design itself, like the schematic and the board layout, in order to fit those needs. So we're stuck with serial in a star architecture. Everything talks to the onboard computer and then transmits information using serial communication. The application layer on top of that, for that we actually made a bold decision and said that we should be using something that is reusable in the future, because that's software, that's much more easily reusable in the future. So the software engineering team took the decision to implement in C the ECSS telecommand packet utilization format. And once again that's a long ECSS, what the hell this is, right? That's a committee for space standardization, basically, among ESSA, the European Space Agency and NASA and other agencies. So we took a really hard stance on that and figured that we should be as future proof and compatible with existing missions as possible. And unfortunately most cubes don't even do that, they just go in and implement whatever they like by themselves. So now at least we have an open source implementation of ECSS standard in C, which is pretty usable for other missions. So yeah, that's the typical layout. And then you go to specifics, right? And the time the clock is ticking and you only have, by that time, like what you have the main layout done, you only have like what, five months to deliver the whole thing, so you don't even have time to order components and get the boards ready and everything else. So many things have to be done in parallel. And as you will see everything was kind of like a discovery process for us. So, well, that's probably day two or day three of the project. Like we said, okay, we're going to 3D print, you know, in a typical Hikerspace fashion. 3D print the design so that we can actually understand the volume of the thing and start pointing to each other where the cables will go and where the components will go. Because we were like just stuck on saying, is that the X minus or the X plus side and I don't even understand how, you know, things are going to be stacking up. So really quickly throwing a design by itself and then have to discover many of the processes. And everyone was talking about, you know, clean room and clean practices in terms of actually handling the space components themselves. And everyone was saying that, you know, without a clean room you cannot do anything, so don't even try to do that and send things in space without a clean room. And we were reading through it and we were trying to dissect the actual instructions and the guidelines and try to identify which are the critical parts of them, right? And which are the things that made sense to apply in our case and which things, you know, that's fine, it's nice to have basically. So things were starting to take shape. Some of the initial structural components were almost finalized so early on so we could actually start building the satellite itself. And then as the time moved on, that's a month in or a month and a half probably. We're starting to see and finalize details about the mechanical components and that's the antenna deployment system, the spool that holds the antennas together and then closes on top of the satellite. On the left you would see a mock-up of the camera that we're using up until the final point because the lens were pretty sensitive actually. The designs were finalizing really quickly in terms of the components themselves. Here you can see the coms subsystem. Oh, a special note actually which is worth telling is that everything we did, we tried and I think that we accomplished most of it to use open source tools to actually do that. So you can recognize that this is KiCAD and we use also FreeCAD and Eclipse for the coding and everything else. And trying to provide feedback also along the process, especially for KiCAD, I think that we provided good feedback on the 3D models library part. And that, if I recall correctly, was useful to them so yeah, open source for contributing back whenever you can. And here you can see down the big block would be the STM microcontroller and then the other two sides, the left upper side would be the CC 1120. That's a transceiver from Texas Instrument, capable of working on VHF and UHF and that's another one down middle right. And the one on the left would be used for transmission from the spacecraft down to Earth and that would be done on UHF frequencies, 435 megahertz. And then the one on the right would be the uplink one, listening to VHF signals from the ground, again on the radioameter band of 2 meters. So things were progressing quite fast and one of the things that you have to use or at least it's a common practice which we found out was really valid to go through is that you don't necessarily consider that everything is space ready in terms of when you try to do prototypes and things. So you start with engineering models and then over the course of iterations and testing and verification and changes in the design you end up with the flight models which you handle kind of like differently in many cases in terms of construction but also the actual handling. Like there is to be a process of who got access to do what on a flight model so that you can keep track of what happened along the way. And that's a typical example of a difference between an engineering model and a flight model. On the right hand it's the engineering model together with the electrolytic capacitors which is a big no-no to space by the way, the out-gas and can go boom. And then on the left side you would see the same board, that's the electrical power system, almost flight ready, that's a flight model almost in there. And I think that the iteration between those two was again like a month or a month and a half probably in that case. So slow progression over things, I'm going to be showing you some pictures of the progression of the satellite itself. Here you can see the satellite still as an engineering model, most of the things were engineering model inside the people that we had which is the one that you see over here. That's a case that we made in order to first off, well carry the satellite, that's important, you cannot just carry it around in a bag. But also that's the vibrational as you will see, jig, that's the place that we have the satellite in in order to do the vibrational testing. And of course those kind of things, even when trying to look through how do we do vibrational testing and find designs about that, there was literally zero information about it online or on other communities. So even that we had to go back and understand what are we trying to accomplish with this process, try to build something, verify that that actually worked on a vibration table as you will see, and then publish the designs openly so that other missions can use it. And they did, like we already know that three different missions, one it's already up in space and two that are upcoming, actually use the design for even a simple thing like that, but we didn't have to rethink whether that was something important or not for them. So we're really happy about that. Same thing for the clean box, you remember that we said without a clean room you cannot do anything? Well we said we're going to do a scaled down version of it, try to find designs about it. You're not going to find anything. It's actually pretty simple, it's a positive pressure box where you have a pump that pumps air through two different HEPA filters inside a box and then the air escapes through the vent on the side which is used also to access the internals of the box so that you make sure that there is no dust and nothing else that comes in contact with things that are cleaned in there. And that box is constantly in circulation, like the air is constantly in circulation, never shuts off so that you can keep doing things. Here is Mantos masking some components in order to be conformally coated as you will see later on. Many times we had to go back and change things in a typical iteration fashion. Here you can see the first boot up of the power amplifier on the COMPS platform and yeah it got pretty heated because it was left on by mistake on the software side of things. But having access to a multitude of tools in a local hacker space which was actually sufficient for creating a whole satellite was for us pretty critical in order to do quick iterations on them. One of the strategies that we used really heavily and that's something which is not necessarily available for most teams designing CubeSats is that because we designed everything and we can reprint and have the boards themselves in multiple quantities then we could have almost every engineer working in the project with a working engineering prototype on their hands which is pretty significant in terms of the fast pace that you need to have in order to start developing things. So if you go out and buy a coach, a commercial and off the self component for a satellite even if it's an engineering model it will cost you approximately, just a module not the satellite the whole thing it will cost you approximately like 2 or 3 or 4,000 euros and then you would have a multitude of that for the flight models themselves. But if you want to equip a full team of 12 engineers working day and night on actually doing such things and you are an university or you are a research institution or a non-profit like us then you are in bad luck unless you have the ability to produce those things yourself and get everyone with an engineering model so they can work really fast on designing and creating code around your satellite. Everything in terms of code was open source the day that the project was created we see unfortunately still many projects that ultimately they do open source not in space but generally they do open source the code but that's something that apparently is I think that happens late after a release or late after the actual usage of the software and we feel and we think that that's a bad practice actually for a multitude of regions for one what's really important is that peer review even for external people that were following the project was actually super influential and helpful towards making a much better engineering design and approach but also it forces like this kind of visibility forces the engineer to work in a completely different paradigm while developing at least that's our observations around it and I know it's up for debate and there's been a lot of discussion around it but we find it really useful to even publish things you know if they're not ready day zero of the project and that's what we did with UPSAT too. You've seen the picture before on the previous talk if you were here that's the UPSAT command and control software that's built on top of SAPNOX ground stations so we just took the ground station code the client code and amended it with telecommand and control capabilities and because we use the ECSS standard that means that every mission that uses the ECSS standard already has a command and control interface to use it and I'm not sure if you've seen before any command and control interface for satellites this looks much better. So the process was really down to the end of it like when we were really approaching the deadlines we started on January pretty much December, January of 2016 and we had to deliver everything by before summer or July, June, July of 2016 but as with everything in space there is a lot of ambiguity around time and time frame. If you've been following the space industry regarding launches and delivery dates of satellites and missions and reports and everything else everything gets to be pushed back, postponed, delayed, change of mission, new launcher coming in well we're actually going to be changing completely the rocket altogether and those kind of things happen all the time in the space industry. So it was really hard for us to for not being part of a space mission before to understand whenever they said that we want this verification test by 1st of May but they actually said we're saying was like well if you can have it by the end of the summer it will be great and that's exactly what happened throughout the process and the project and it was really frustrating especially in the first times that actually happened but now we know and we know how to deal with it. So you can see the satellite in the clean box next to it it's an engineering steel part of it so it can be outside and then the satellite gets to be completed and the test is almost ready the software is almost ready and you're really trying to finalize and make all the details sorted out regarding the software and the verification of the functionality so you go into what we call a testing campaign which is practically a number of tests that are happening on top of the satellite or top of the thinnest satellite. So the first one would be the vibrational campaign so you can see the aluminum box that we had the people that we had mounted on top of the vibrational table which is pretty much a giant sound vibrator that's what it is and you have a couple of accelerometers making sure that you have the responses logged so you can see the resonant frequencies and how it performed on various different profiles of vibration and that's basically to emulate the rocket launch itself so the shock that you're going to be having on your satellite from the rocket launch you want to emulate it as close as possible in order to see if things are going to be failing So in theory you should be doing that more than once We actually did it more than once so that we can verify some of the things and it all turned out really great The best way to prepare yourself for this thing is probably to do some good simulations in terms of a mechanical structural engineering for the resonant frequencies and everything around them but also to follow some good practices in terms of well don't have loose things and loose cables all around your satellite which might seem pretty obvious when you hear it for the first time but it's not really when you're trying to and no one told you how to do those things Then the second part of the testing campaign would be the thermal vacuum testing and in here you can see the satellite that is inside the vacuum chamber which is pretty obvious that we constructed ourselves and it worked pretty fine it was able to achieve the vacuum state that we actually needed for it and then inside the vacuum while the satellite is in vacuum then you do what we call thermal cycling and that would be exposing the satellite to things that it's going to be seeing in space and the fluctuations would be from minus 20 degrees centigrade Celsius to plus 50 degrees Celsius and that would happen again and again and again and you would run different tests while this was happening so the satellite was still operational for this process to identify any troubles with the actual setup of the satellite itself That's the satellite as it has just ended the thermal vacuum testing and you do what we call a total mass loss measurement which is basically you measure the satellite before it goes inside the thermal vacuum testing and then after it so that if anything has outgassed like moved away from the process of being exposed in vacuum then you would identify what this was and there is a certain percentage of loss that is acceptable basically and we were well within margin in our case and then the final part is the EMC electromagnetic compatibility and electromagnetic interference testing for that unfortunately we couldn't construct an anechoic chamber ourselves although it's in the to-do list for various reasons and we had to resort to facilities in Greece that actually could do and have the specifications to do that and one of the things that you do on EMC and EMI testing is well first of you make sure that your satellite is not susceptible to any type of interference so you just bombard it with RF signals and make sure that things are still functioning as they should and then the other way around like you make sure that your satellite is not really causing interference to something else and in our case because the satellite would be going up to space to be deployed from the international space station which is a human rated environment, it has astronauts inside it's super critical for us to be able to showcase that we're not going to be doing any fancy things around ISS so here you can see the final delivery pictures of the satellite itself ourselves delivering the satellite super happy to facilities of the integrator in Netherlands that's the final piece of the satellite that was missing and was put in place by the team there which is basically the bias probe, part of the science unit and then that's the official picture of the satellite to be delivered and then the next thing that happens is that the satellite goes inside an aluminum box which is what we call a deployer it has some neighbors next to it so you can see our satellite which is here in the center and then on the right side you can see a friend's satellite which was riding with us and in this aluminum box there would be also an Israeli satellite so three satellites all in one aluminum box and the concept is that that box would go up in space through a cargo module to the ISS and then in there once it is out in space at some point when the astronauts had time and the time schedule was okay the door would open and the spring would push out the three satellites and that's how you get to be deployed in space through that route so we delivered everything and everything was in place in August 2016 and we have passed the verification tests and we were all anxious about the satellite launch well the launch of the rocket in space and then the satellite launch from the ISS and then you wait and you wait more and you wait some more because as we said much delays are happening unexpected and you don't even know what's really happening around it so when we were on the outside looking in following being space nerds and following the procedures and what's happening and why this has been a delay about things we were just assuming that well we are on the outside so we never know why a satellite was delayed or why a launch of a rocket was delayed I can assure you 100% that that's the same case even if you have your own satellite inside the rocket and you get delays and delays after delays and no real explanation about what was causing those delays except apart from the obvious ones I mean if it's last minute weather delay that's fine but delays on integration of the deployer on top of the rocket for two months you know what was happening so at some point the time comes and you can see the rocket going up and you know that your payload is in there and you're super happy about it that's a Cygnus cargo to ISS that's the OA7 mission that went up the 17th of April 2016 and it went in the ISS and guess what once you are in the ISS after three or four days you docked on there and then you wait again because you know things have to be in place in terms of the schedule of the astronaut and everyone else and at some point after a whole month of being in space and we gather from previous information that is actually quite short time of waiting on the ISS there have been missions that have been waiting for deployment on the ISS more than a year and that can be detrimental for the mission obviously especially for the battery part of it and then the magical moment happens and you get your satellite deployed in space and then you wait again although this time the wait is actually much shorter and it's much shorter it's just 30 minutes and it's 30 really horrific minutes that the satellite has to stay silent in order to move away that's actually a requirement when you're launching from the ISS and just you wait for the satellite to separate enough from the International Space Station and then start beaconing on top of it well on top of the frequencies that you were listening to it so we knew when this was happening and we had the satnox network like multiple different ground stations around the world like listening for a specific frequency and then just 30 minutes after that rightfully not even in our own ground station in the ground station of one of our contributors in Indiana in the United States we got the signal and that was the signal which you can barely hear through the microphone here and that was the CW beacon together with some FSK frames of the satellite itself which meant that the satellite was successfully deployed in space and could phone back home you can see the typical FFT diagram here like a waterfall the signals that are aligned are basically FSK 9600 frames and then you can also see the dots which are the CW beacon which we had for contingency reasons like just to make sure that if everything fails at least we will get the CW beacon like a Morse code beacon right and then the information starts putting in and then you see the gradual charge and discharge of the things that the satellite is doing itself and we are super happy to see everything functioning as expected although one thing didn't really function as expected and that was the hitters of the battery themselves actually they did function as expected but more than they should so they were constantly draining more power than we were actually able to generate and that caused an up until today actually the satellite to be in a oscillation between safe mode of the battery just to make sure that it generates enough power from the solar panels to charge the batteries and then from the batteries powering all the different systems so what we see right now on the satellite is this like there is a safe mode that is happening and then it charges enough in order to open up again communicate with us and then go again back to safe mode so what we learned you know overly about the whole process is that it's not really rocket science I mean we documented it we know how it was done we will do it again most probably actually 100% surely not in the same way we've learned many things that we should change and hopefully this experience is also conveyed through the repositories themselves and what we set out to do after that was ok cool we could have settled for that and said well we said the first open source satellite in space but then what so we decided that we should actually take it a step further so we partnered together with a group inside the ESA the European Space Agency and we created the first open source CubeSat workshop which successfully ran last November in the ESA facilities in Darmstadt in order to start creating a community of space open source in space the workshop was pretty successful we had many participants either interested or setting what they're willing to open source in terms of that being inspired by what we've done on the satellite but also really understanding the value of open source in all different kinds of things on the engineering value of it the business model probably value of it and everything in between so that we can advance it so we created the community and we have a website about it community.libre.space and in there we're trying to exchange that so that's a call to action call for participation to all of you if you like space and you're well versed on something or you want to learn something new please do come find us I know it's the last penultimate talk of FOSDEM so it's kind of weird to come find us right now but feel free to reach out to Libre Space Foundation and we have many upcoming projects open source projects and we'd love to create as many open source projects in space altogether so we can completely change that industry and revolutionize it with open source so thank you a lot for your time Is there anybody who's Christian? Hi, there are a lot of university space programs I know in the US in like the University of Colorado Cal Poly, my old home university are none of these sharing their CubeSat designs because they're all doing CubeSats and they're all getting launches and I would assume there's something coming back into the community from that So up until now because we've been searching a lot about it and we keep doing that and trying to persuade people to actually open source their designs the only mission and the only university in US that is doing it right now a next mission it still hasn't got to space it's Oresat from the Oregon Portland University they have been doing a phenomenal job of documenting their process and building an open source satellite which we hope that it's going to be successful in space Hey, thank you How do you turn the satellite so that the camera points to the earth? How do you what? How do you turn the satellite or do you control the orientation? The control of the satellite, yes We have two different actuating mechanisms in the satellite itself so the concept is that you have magneto-torquers so you imagine coils on the back of the solar panels which create a magnetic field that using the vector from the magnetic field of the earth you create torque so that's minimal but dominant enough to actually turn your satellite around and in combination with that we also do have a spin-torquer which is a flywheel basically on top of a motor that stabilizes the movement of the satellite on two axes like a gyroscope so it's much easier to do that in the next one Another question How about thrusters? Most cubesets don't have any thruster system and I can imagine that in general working with liquids is super hard Is there any research or things available about thruster systems open source? So thrusters on cubesets are super expensive right now not open source so we'd love to work on developing such a thing in the future I guess the final one So that's it, thank you