 Hi, so my name is Ray Ramadurai. I am principal avionics at Planetary Resources, and what that means is I'm responsible for the hardware and the software that goes into our vehicles and ground stations. Before that I worked at Intel for about 12 years working on microprocessor architecture, design and so forth, did some stuff on the Core i7, the power management stuff, turbo feature, things like that. Back in 2011 I saw that this company was getting started in Bellevue, Washington, and I gave the president a call and said, what are you guys up to? I should introduce Mark Allen. Mark Allen is a senior software developer. He is one of our refugees from JPL. We recruited him out of there. While he was at JPL he worked on the MSL second chance landing software, which was a suite of landing software that was intended to take over in case there was a crash on the flight computer as Curiosity was descending to the surface of Mars. He's one of the few software engineers I've met who is happy that his code did not actually get executed as part of that mission. You might be asking yourself, asteroid mining? Is this for real? Are these guys at the wrong conference? What in the world does any of this have to do with Linux? You really see a very interesting opportunity for new space to incorporate a lot of the open source methodologies, the open source solutions, and Linux in particular into our spacecraft and so forth. Mark's going to talk a little bit about the history of other spacecraft OS approaches and why they don't necessarily map well. But specifically to this conference what we've done is we've looked at a data center and we've looked at a spacecraft and there's a tremendous amount of very interesting overlap in between the two. If you look at the problems that you might have in the context of dealing with a failed node somewhere or if you look at the problems of dealing with widely distributed faults or in particular power, I mean just power efficiency is a huge one, many of these spacecraft are powered by solar so they will want to be as power efficient as possible and we see a significant overlap in between the two. There's also some unique problems on each side of them but when you have that there's an interesting opportunity to leverage what's already been done and we try and pull in as much of that as possible into the development of our flight software. Okay so before we step into the tech what I'm going to do is talk a little bit about asteroids, asteroid mining just to give a little bit of context there and then we'll talk about the spacecraft technology and some of the ways in which we're using Linux and open source solutions. Any questions before I continue? Okay so why asteroids, why now? We think as a company that we've reached the point at which it is technically viable to build small spacecraft to go out and do prospecting and eventually mining of near earth objects. This is the convergence of a lot of different technologies that have come together over the last couple years and then second you know we tend to be a little bit idealistic at planetary, you know we think this is the next step. A lot of us, a lot of people there are former JPL or NASA people, I myself was a huge space fan as a kid and so forth but it's also a business and we think that near earth objects actually represent a interesting potential for significant financial return. But more specifically there's a lot that sort of come together that's enabling us to do this. First of all asteroids have been showing up quite a bit in the news lately so if you think about the Chelyabinsk event that happened earlier in the year and this is when a large bull-eyed came in that nobody knew about, nobody had seen it or cataloged it at all, came in and struck in northern Russia. That NASA has a program right now, they're talking about bringing back a near earth object and putting it into orbit around the moon. So there's a lot of interest in this arena at the moment and we think this is a neat time to go off and start doing this. In addition there's been quite a bit of planetary science over the last couple years that has shown how many of these objects there are, where they're coming from, what they're made of and that has really changed the emphasis on it. I'll show you a slide here in a moment that when I first saw it and when we first put it together was an eye-opener for how many of these objects there really are. Next accessible launch is really changing within the small spacecraft world. So between SpaceX and Orbital Sciences and some of these other small, some of these up and coming commercial providers, the potential for getting things into orbit for less than tens to hundreds of millions of dollars is starting to exist and it's becoming quite a bit more available. Universities have been availing themselves of this to get CubeSats up into orbit and so on and so forth, but now small spacecraft companies and small groups are able to do similar things because of the fact that launch is becoming a little bit more accessible. It's not becoming broadly accessible and the cost isn't necessarily coming down, but at least there's availability that wasn't there before. In fact, tomorrow there's a launch of the first Cygnus, which is an Orbital Sciences vehicle if you're interested in watching launches. Okay, second, there's a lot of things happening in the small satellite industry between companies like Skybox, I don't remember all the other ones, but there are a variety of different ones that are putting up things for doing Earth observation and they are doing data providing for container shipment and things like that. There's a lot of interesting stuff that's happening in the commercial market here and we actually are focused outward. We're actually looking at taking this from a leaving Earth orbit and going interplanetary, but being able to get up there and have a lot of these different companies that are building similar kinds of hardware is quite exciting and it's a real opportunity for us. Okay, there's also a neat thing happening because of Moore's law and so forth. Commercial electronics are reaching the point at which the compute efficiency, the power per unit, the MIPS per unit watt, the capabilities, whether it's virtualization, etc., are crossing over to what is required to actually do a high reliability spacecraft project. And as we're seeing that happen, we're trying to leverage those technologies and use them successfully in our spacecraft. This concept of using COTS or commercial off the shelf hardware has existed for years, but there's a lot of resistance within the aerospace industry to it. And we're hoping that we can actually demonstrate that. And part of the real philosophy there is because of the fact that we don't have to be completely perfect in our operation. It's okay if we crash occasionally. We can actually survive with commodity hardware as opposed to having to have the highest reliability, highest functionality hardware that might go into a scientific mission. Okay, because we've got commodity hardware and we have this type of infrastructure that we can leverage, a small company can actually build one of these things, I think, now. And the way that you do it is you leverage as much of the existing infrastructure as possible. Our software team is a couple of guys, and it would be impossible for them to go and write all the spacecraft code that we have. So I estimate we'll probably end up writing on the order of 5 to 10% of the overall code on a line by line basis of what actually ends up in the spacecraft. That's a huge amount of code. But we can leverage things like the Linux kernel, we can leverage open source and so forth to provide a lot of the interesting infrastructure that would otherwise be written from scratch. And finally, this is a long-term endeavor. We talk about asteroid mining and it's a long-term goal. What we're really working on right now has to do with small satellites that we're putting up in near Earth orbit to validate the technology and figure out where to go from there. All right, I think I'm going to actually skip this slide. This is sort of the company goals and objectives and so forth. But the idea is we want to go out and mine asteroids and so forth. But I do want to give just a little bit of background. So the company was founded by Peter Diamandis and Eric Anderson. Eric Anderson is the guy that started Space Adventures, which is the space tourism company. These are the, anybody who wants to go up to ISS and so forth, they would go through Space Adventures. And then Peter Diamandis is the chairman of the X-Prize. So there are a variety of interesting X-Prizes that have been done, the Anasari X-Prize, et cetera. They've got a current one that's going on for some lunar rovers and so forth. Chris Licky was the youngest flight director ever, and I think he was the flight director for Spirit and Opportunity, the two rovers that were on Mars for so long. And Chris and Peter worked extensively on Curiosity, the rover that's rolling around right now. All right. So I really like this slide. Let me see if I can get it to play. So in 1990, there were about 9,000 known objects, known near-Earth objects. And at that time, there was just beginning to be real interest in it. And what you're seeing here is every time there's a flash, there's another pixel that shows up there, that's discovery of an individual asteroid. That number grew enormously because of the number of space surveys that came online as a result of things like the Shoemaker-Levy comet impact that hit Jupiter. And when you start to look at it and you see how many of these objects there are, it really changes your perspective on the solar system. It's not just the eight or nine planets, depending on your perspective. It's hundreds of thousands, and actually estimates of 1.9 million, not near-Earth, but overall objects. So there's a lot of material that's out there. OK, so there are approximately 1.5 million objects in this solar system. There are about 1,000 of these that are larger than a kilometer that are what are called near-Earth asteroids, meaning that they intersect Earth's orbit or that they're reasonably close from an energy standpoint. And then there are about 20,000 that are about 100 meters in diameter. The interesting thing about these is it's not so much about the distance to them. It's about how much energy it takes to get to and from them. So 17% of these require less energy to get to than it requires to get to the moon. And that number goes up when you think about the return energy required to get back. So this is typically calculated in what's called delta V. And that makes these very accessible. They're easier to get to than going to the moon. Come on, slide change. There we go. OK, this slide is sort of a collection of different asteroids that have been visited by various different spacecraft over time. And you don't get these kind of images from Earth telescopes. You have to get very close to get this kind of imagery. So these are from things like Hayabusa, from Dawn. They're very different probes that have gone out over time and looked at these. To give you a sense of perspective on exactly how big they are, sort of get a feel for the size. That's to scale. Exactly. One of my favorites is it would be a lander. Now, because of the size of these, you don't really land on them so much as dock with them. But we think with something like the 300, we would be able to go out, collect a small amount of material, bring it back, demonstrate the capability, and so forth. That's odd. OK. So just to give you a size perspective, this is the A100. It's built in what's called a 12-view form factor. So there's a standard that's called a CubeSat standard. And it's a 10 centimeter on a side cube. And when you put a bunch of these together, you can get into fairly standard launch vehicle sizes. This is a 12-view configuration, which means that when it's in the stowed form, the panels are folded up and so forth. In the back of it here is where the avionics and all of the electronic hardware is. These are the solar panels on the backside. And then we have a deployable 8-inch optic. One of the key things that we think will enable us to do very small spacecraft is dual use of systems. So for example, the primary optic also will double as our primary communication system by using laser com. And the problem when you're a couple AU out from earth is you can't generate enough RF power to go out in all directions. So you have to have a directed beam. And we certainly can't afford to make use of the deep space network on a continuous basis the way NASA or JPL could. So we think laser com is a very appropriate approach for solving that problem. And then finally, I skipped a slide there. Yeah. And then finally, the problem when you're one or two AU out, the light time, the act time on a single TCP packet is like 32 minutes. So by the time you've received the fault or the condition or whatever the case may be, 32 minutes have passed. And you have no idea what happened. So autonomy is absolutely critical. And if you think about the problem of autonomy, there's a lot of simulation involved. There's a lot of analysis involved. So you need quite a bit of compute. And that really pushes us towards some of the more modern hardware. Speaking of which, this is the Rad 750. This is a power PC-based architecture. And it represents the standby for most interplanetary spacecraft. It runs at a blazing 133 megahertz. And typical systems here we'll have on the order of a couple hundred megs of RAM and mega or two of non-volatile storage. It's rad hard, though. That's its heritage and ridiculously expensive. We think that we can leverage something a little bit more modern. So take the Z5 there. It's several years out of date at this point. But it contains support for things like virtualization. 10x the speed, a fifth of the power, and a 200th of the cost. But again, it doesn't have to be perfect. It doesn't have to survive every single event upset. It just has to be good enough for us to do the mission. And if I use a number of these together and do redundancy in different forms, I can get the same kind of reliability that I potentially would have out of something like the Red Sun 50. All right, so deep space data center. I'm going to talk about just some of the places in which we're using open source software and Linux. And we'll start with the OS. We really want to run a fairly straightforward Linux solution, either with Yachto or maybe Buildroot. We're still working on which one we like better in that context. But the key thing here is we actually want to run it both on the ground and in the spacecraft. We can't afford to go and write a completely different messaging layer for our spacecraft versus what we do on the ground. Now, obviously, the disk may be different or the exact usage will be different. But we want to have the same tools, whether they're on the vehicle, on the ground, or in the cloud. So the core flight software is written to sit on top of that. We make extensive use of Ethernet. And then this is an interesting concept that we've been working on. Having our telemetry go to an on-vehicle SQL database as opposed to having it be just text files, which is how it's traditionally done. And then we're playing with the idea of using MDRAID to see if we can make SSDs a little bit more reliable. And then finally, we want to be able to do simulations. We want to be able to do Monte Carlo simulations of the entire flight software within a cloud environment. So we'll take the system as a whole, instantiate 10,000 of them, and then put faults into each one and see how our flight software responds to it. And then just as would be expected, all of our development tools, all of this kind of stuff are set up so we can run them effectively in a cloud environment. And with that, I'm going to switch over to Mark here, who's going to talk in detail about a few pieces. Sorry about that, guys. All right. So Ray mentioned a lot of reasons why we're looking at Linux and open source and commodity hardware. And I'm going to give you more details on how that works and our motivations there. And as he mentioned also, I'm originally from a more traditional aerospace background. I worked at JPL for five years on flight software there. So working with guys like Ray at Planetary who have been doing cutting edge stuff for the last few years and kind of the mix of both worlds at Planetary, we have a different way of approaching these problems, kind of combining the best of both, hopefully. And to that point, traditional missions, deep space missions in particular, are very expensive. They require decades of work a lot of the time, hundreds of thousands of people, the billions of dollars in the works. And so they're very risk conservative. They basically will find a thing that works and they'll use it forever. And that's for good reason. They're really focused on the science. And the engineering is really only existing to serve the purpose of creating more science. So there's not really an incentive necessarily for them to go do brand new things or push the boundaries in significant ways. And additionally, they only produce a couple of vehicles per program typically. You might have two or three. That'd be kind of unusual. There's some new programs coming on which will make swarms of satellites, but those are just coming to the fore. So we have a very different motivations and a different philosophy. So we're approaching this from a business perspective. And we need to create for ourselves many opportunities to interact with asteroids and acquire asteroid data. Because we don't have a lot of information on the asteroids really. The odds of going out to a given asteroid and successfully finding the right one to mine are pretty low. So we really are looking for the ability to create many, many satellites so we can fly very often. And that sort of implies we're mass production, commodity, cheap hardware, and a platform that can evolve and change rapidly over time as we have the opportunity to do that. And you don't have the chance to really do that with traditional once every few years type missions. We're going to fly hopefully multiple times a year and try new things fairly often. So that allows us to do things like incorporate open source and Linux and commodity hardware and experiment to find the right way to do it. And there's a lot of reasons why we wanted to take this approach. The other reason is we want a long term sustainable strategy. We can't be relying on the same hardware forever. We need to be able to constantly evolve and change. So for these reasons, it's really important for us as a low cost spacecraft developer to try something else, which in this case, Linux and open source and quantity hardware is kind of the way to go. So what this offers us, which is pretty standard for you guys probably, but coming from the aerospace world, you have these silos where the flat software is a silo, the ground software is a silo, simulation is its own thing. And these guys don't have a lot of incentives to reuse or find commonality across their platforms. But now we can see Linux being the spacecraft operating system. It can be the operations framework. It can be the simulation framework. And it's how we develop our code. So we use Linux just everywhere. And that's very advantageous for us. We can reuse software across all these different environments and different venues. It can be in the cloud, on the ground software, in our office or in space. So that's definitely an important factor for us. And open source and the cloud especially has had a really strong, created a lot of tools recently that we've been able to use for spacecraft development, which has been really important. Pretty much everything that you could imagine using for a small web startup in Silicon Valley, we can also use to accelerate our development and make us more efficient. And of course, there's so much software available. There's a solution for any given engineering problem that we're going to tackle in flat software, ground software. And it's just a matter of trying to find the right way to stitch it together in a higher liability system. And that's where it's a little bit more complex for us. But we think there are ways to do that. And of course, there are many more talented engineers around the world using Linux. If you have a proprietary system that only a few people in the world know how to use, the odds of getting new ideas and more motivation into your program is not as good. So having more perspectives and a deeper pool of people to draw upon is very beneficial. As a concrete example of what we're talking about, let's talk about inter-process communication. So on a traditional spacecraft, you're running in RTOS, like VxWorks, maybe a uniform memory space. You're going to write off of scratch, essentially. You're going to write the state machines from scratch by hand. You're going to have your own messaging layer. It's all going to be something you have to maintain forever. So we're taking a different approach to that, where we want to basically take a bunch of different open source libraries and tools out there and tie them together using auto-generated code for the most part. So we can take models of state machines in XML and messaging in XML, use Python tools to generate code via protobuf and cheetah. And then on the spacecraft in the runtime environment, we can use something like 0MQ in Linux, which is normally used in financial systems and low-latency messaging applications, along with the quantum framework, which is an open-source state machine framework, which is really great. I don't know if anyone has heard of it here. And Nanopv is also another really cool library we came across, which allows you to do embedded protobuf serialization and deserialization in a more deterministic and fixed way, where you don't have the STL or dynamic allocation available. You can use NanopvB. So it's a pretty cool tool. So something like this allows us to save a lot of time and just why reinvent the wheel. It's very powerful, and it allows us to leverage these same open standards and open software tools at all levels of our system, included in the ground. And virtualization is another important thing for us. It plays a role in all of our contexts. And we use it for running the mill stuff the way you guys probably do all the time for IT, for enterprise, for building your software. But it's also applicable on the spacecraft. You might ask yourself, why has no one ever done virtualization on a spacecraft before? Well, if you look at the RAID 750, that's 15 years at a date by now. There's no way to do virtualization on that platform, and that's kind of the position that most of these programs are in. So if we take a step forward and try to learn how to use commodity hardware in space, we could certainly take advantage of virtualization and all the benefits that it offers us as a real-time system in space that has a lot of risks and vulnerabilities. So there are obvious benefits for this. We can decouple the hardware and the software, so we can continually evolve the hardware platform and make changes without having to re-verify and redevelop large swaths of the software. And that's really important for us as a very small company. We can't spend a ton of time revalidating the software every time we tweak a small thing in the hardware. So this is really great. And then we can deploy payloads, independent payloads, to the spacecraft without huge concerns about adversely affecting the spacecraft or each other. And that allows us to add maybe new instrument, like a new radar, add a customer payload. And I think it's important to point out that in solving this really hard problem of asteroid mining, it's kind of like when Apollo was underway in the 70s, NASA had to find new ways to do things because it was too power, hungry, and too massive efficient the way they were doing it. They had to basically invent the microchip to make it reasonable. We're going to have kind of collateral technology development as part of this that we hopefully can leverage in other areas other than just asteroid mining. I think that solving these problems in this new way will be applicable across many different applications. So one kind of more interesting example of this is using hypervisor on the spacecraft to emulate hardware redundancy. So radiation is a huge problem in space. How many of you have had some strange hardware anomaly that's caused a bug in your flat software and caused you days or weeks of pain and trying to debug it? Anybody? All right, well, I think this is more common in data centers than other venues probably because there's so much hardware and it's more commodity. It's kind of inexpensive. So you have a lot of potentially hardware issues to deal with. And in space, that's true in spades. We have a radiation environment where the sun is generating particles that can fly into the spacecraft and cause bits to be flipped, corrupting state and damaging hardware and potentially killing hardware. So it's a very unfriendly environment to electronics and to software. So this is the kind of thing that keeps me up at night. How do we design a system to not be totally vulnerable in this case? So the hypervisor can provide one avenue for emulating traditional TMR, which is where you basically vote three signals together and the majority wins. So if you have one misbehaving entity, we have three identical virtual machines here. They're all getting identical inputs. And they're computing some kind of GNC control algorithm, which is what's the next thruster output. If one of them is halted or has cryptid state, which causes it to give you a huge value, which would destroy the spacecraft, we can vote that out. And I'll be the first to agree that this simple diagram has a lot of complexity. But for us, it's massively important that we not develop Boutique hardware for this purpose. So we have to maintain forever. And we want to try to leverage this in a generic way, where this is kind of platform-independent TMR, where you don't have to know anything about what you're actually doing at the software level or the hardware level. It just knows that here's I.O. and this I.O. has to be correct. So that's very important for us. We think this could be a way we can leverage virtualization in these other platforms in a new way. And we plan to fly a hypervisor on our first mission sometime next year. It's kind of a proof of concept. Try it out operationally. See how it works. If you have any ideas for that, we'd love to hear them. Another analog to the data center we could talk about is the data story in terms of how we acquire data, process data, and deliver data to our users. So we sound like an asteroid mining company, like we're with pickaxes on the asteroid, actually trying to get ore off of the thing manually. But we're really a data company at first. We need to go out there and find the asteroids of value, figure out where the right ones are, when they're going to come around so we can access them. And that's really our fundamental value to our customers and to ourselves right now. So if we can't deliver data, we're not really very valuable. So we don't have the DSN either to leverage in terms of traditional methods of getting data down, as Ray talked about. We don't have the resources to do that. So we have to find new ways to be more efficient about it. So you can imagine that relational databases or like a NoSQL database is kind of a natural thing you might want to use for this purpose. You have data that's very well structured. You can easily query it. But this is never, well, I don't say never, but it's uncommon in spacecraft, mainly because of the RTOS issue. It's difficult to get it compiling. The process model is very different. And for risk reasons and heritage reasons, this is just not typically done. But we're learning Linux, so why not give it a try? And there are a few challenges that we'll talk about in the next few slides here. But we think we can make this work. So a spacecraft has very limited communication windows. You have a latency issue that Ray talked about. And there's a line of sight issue where you have two moving bodies, and they're both rotating. So you have very small time windows where you can actually conduct communication. And we have a lot of data on the spacecraft. We have images potentially. We have a whole host of metadata about the asteroid. And we want to sort of mirror a subset of that data down to the ground, but only the stuff we care about. We have too much data to get it all down, so we can't kind of go through and cherry pick it and have a luxury of deciding what exactly we want with the full data set. And we can't keep it forever because the spacecraft is very limited. So I feel a little bit smarter about this. And traditional systems really just, they'll tell you basically what type of data is on the spacecraft, but you don't know what exactly is in it. So you can't be very efficient in terms of what you choose to download. You're going to get a lot of stuff you don't really care about. So using SQL, we can say something like, give me all the times when this device exceeded a certain voltage threshold, and that'll help you maybe debug a power issue, maybe something's consuming too much power. You can tell the spacecraft a priori. Here's the stuff I care about on the next comm window. Prepare to assemble this data set for me and deliver it as best as you can. Maybe it's too much data for one compass, but it'll kind of figure it out as we go. And this kind of allows you to, with very little information, tell the spacecraft what you really care about. And this is, again, not rocket science, but in spaces has not typically done. So by using Linux and open source technology, we are able to do a little better than we have before. Integrity is the other major issue with using a database in space. We're using commercial, solid state disks, we're using commercial disk controllers. This stuff is not meant to fly in space. So we have to think about how we can incorporate a database like this and actually make it reliable enough to be useful. So there are a couple of ways we can do that. The first is just we have to design, at our level, for faults. The absence of the database should not be a fatal event for the spacecraft. We have to have good defaults. We have to be able to handle missing data or connections that are not available. And that's just kind of on us to do. We can partition critical data away. So you have a separate database for, like, configuration and state data, which is very small. That can live in maybe a more radius and hard e-prom. Or non-critical data, which is telemetry, that can live in the SSDs. Losing that's OK. We can deal with the fact that we might lose telemetry once in a while. And again, this is, we're not NASA, so we'd have to have 100% reliability. This is kind of, we have more freedom to experiment and take a little bit more risk here. ECC is another important thing for us. When the database is in memory, we have a flight computer that has ECC to protect us. And that's another area where the blade servers have kind of pushed the feature that was normally high end into commodity hardware. And we can finally take advantage of that with very inexpensive flight hardware. And at the file system or database level, we can also use ECC. And then there's RAID as well, which is, again, this is kind of a no-brainer for data centers. But in space, typically RAID is not the way this is done. We can use something like MD RAID to, inexpensively, and with very little hardware, provide disk redundancy and protect against corruption of data. And the last thing I'll talk about is the cloud. Like everyone else, we use the cloud to scale to, for data storage, data processing, all the things we've talked about already. We can create a lot of data with the spacecraft, not as much as most of you guys, though. But what we can do that's more interesting from a spacecraft perspective with the cloud is do Monte Carlo type test campaigns, where let's say you've got a critical event, like an asteroid rendezvous. You want to simulate that with 1,000 different asteroid rotations or centers of gravity or spin axes. And you can seed the software simulation with all those different cases and run them in the cloud and with the flight software in the loop. How's it going to perform? And maybe inject faults at different time steps within that scenario. And this is important for us as a very, very small team. We can't possibly test every case we care about. And test by time is very hard to get with the actual hardware. So this is kind of a requirement for us to get the reliability that we need. And you might be wondering about ITAR. ITAR is definitely an issue for the cloud, for us, because data can be anywhere. And who has access to your data and to your products can be anywhere, pretty much. So Amazon is a new product called GovCloud, which is ITAR compliant. And that's the thing we're looking at to help us get this sort of sensitive information into the cloud and utilize it in the way that I've just described. I'll bring Ray back up here now for the last view. OK, so I just wanted to make a quick pitch. We are looking to hire software and hardware engineers. We've got a few open positions, so if you're interested, bring a resume or a card or send a note. You can go to the website as well. And finally, I think we've got a little time for questions. So you talked about simulated triple over dot and with the three VMs, right? But do you have any, sorry, so that doesn't protect against any corruption in the hypervisor, right? Is there a good solution to that? So that's correct. It doesn't do anything for the hypervisor. But if you look at the amount of residency time in the hypervisor and the size of the memory footprint there, it's substantially less. So what this is giving us is a solution that may take us from a reset case where we're resetting three, four times an hour to something where we're resetting once a day, right? Because the goal here is not to get perfect. The goal here is to be able to survive long enough that we can actually successfully manage the faults. So yes, but here the trick is you're not spending a ton of time in the hypervisor for the most part and the memory footprint small. It's a probabilistic game with the radiation. So it's about cross-sectional area and what's vulnerable. So we're making less of a software vulnerable, basically. Other questions? I got two, I guess. Are you worried about SQL and all this being massively complex versus traditional space software? I mean, it's a general purpose solution that seems like it has a lot of extra code that could easily just crash for reasons that just didn't need those features kind of thing. And the second question that's completely different is, have you ever thought about putting like a relay station in orbit to collect all the data, all the extra data from the satellite you're talking about, and then that would give you more bandwidth back down to the ground? OK, so let me just talk very briefly about the database question. We're still evaluating different databases. It's absolutely a concern. But unless you're going to go off and write a custom solution, you're going to have to take a certain amount of dead code that you wouldn't otherwise be needing. So yes, there's a certain amount of risk there. We haven't picked the appropriate final solution yet. We actually spent quite a bit of time looking at SQL Lite just because of some interesting properties that it has. But its performance, for other reasons, wasn't appropriate. So the answer is we haven't really picked quite the right solution in that space yet. This is a general philosophical design question, I guess, about how you integrate open source and stuff that isn't necessarily meant for higher reliability systems or for real-time systems into a real-time system like the spacecraft. So we have to think carefully at how we do that. And the database is a great example where you have a server that could be servicing any requests, and your real-time threads can't get blocked on interacting with that piece of software. So we have to use asynchronous methods, I think, to prevent that. And Linux provides, I guess I come from this VxWorks context originally where it's one giant memory space. Just having processes is such a big jump that having a database like SQL is not that scary to me. I think we can solve that problem. And it's been solved before. And then you'd asked about relays and so forth. The COM problem is a really, really complicated one. And the challenge there is pointing more than anything. We don't specifically have the notion of an individual relay like that that you build out. But because everything's moving all the time, it's very difficult to sort of have a relay that you can point back like that. But what we have talked about is developing a symmetric spacecraft where you have one whose purpose is to relay back and then you have a swarm at the object, at the asteroid. And then they all communicate locally and then send back. And that is a concept that we've thought about. It's very exciting. Other questions? Good question. You were talking about the generations of the arcade telescopes that you want to send out. What are the timeframes that you all are thinking of? Any ideas? Just curious. So exact timeframes are TBD. We're still figuring it out exactly where everything's going to line up. I will say that we do have launch manifests for next year for a early hardware prototype that we're working on. And we'll see things going up from there. But the problem with launch is that you get moved around all the time. And you never know what vehicle's available when and so forth. So it's very difficult to nail down a particular one and say, I'm launching on this exact vehicle, on this exact date. So the question was, who are you launching with? And for the same reasons, it moves around. I can't specifically answer that. So you mentioned why you can't do TCP, because the handshake would take too long. Are you still using IP? Are you using IP 4 or 6? What is your layer to pack it to laser com encoding? So we're not doing TCP. And maybe we can talk about this separately. This is a new area that we're just working in. So I don't want to get into too many details there. But there are some high latency protocols. And if you do a little bit of research, there's some very good high latency protocols that are effective for this kind of thing. And we're looking at incorporating one of those into a networking stack. One more question? So you get an advantage for writing your flight software as regular Linux processes that you can run in other environments. At NASA, there was work by Goddard to build something called the core flight executive that would achieve sort of the same goal without having to run Linux on their embedded board. Have you looked at that sort of approach so you can run a real time OS on your vehicles? Yeah, I took a look at the core flight software. Being from JPL, we looked at that as well there. I think that the idea of trying to run Linux in every context, including in the cloud and in the virtual environment and in the ground station, kind of implies that we want a more general solution. And Linux is, I think, a better platform for that than the core flight executive. And I think there are some other architectural considerations that we wanted, things that we wanted that the core flight software didn't quite provide, though I think it's a good baseline. OK, thank you very much for coming. I appreciate the time.