Episode 24 of the Space Industry podcast is a discussion with Viktor Danchev, Chief Technology Officer at satsearch member EnduroSat about interface planning, testing, integration, and other challenges faced in the development of a satellite mission.
Episode show notes
EnduroSat is a nanosatellite manufacturer and operator with headquarters in Bulgaria.
EnduroSat has built a strong brand in the space sector since being founded in 2015 and has worked with customers all across the globe. In the show we discuss:
- The pros and cons of the standardization of satellite sub-system interfaces
- How teams can work better with satellite platform providers remotely
- The ways that equipment tests (such as hardware and software in the loop) can be run between collaborating teams
- How proprietary technologies and data can be protected in shared missions
The portfolio of EnduroSat
The EnduroSat 6U Deployable Solar Array is a deployable, radiation-tolerant CubeSat solar array featuring triple junction solar cells, an integrated magnetorquer, redundant burnwire mechanism with feedback configurable for X/Y or Z side deployment.
The EnduroSat 6U Solar Panel is an adaptable CubeSat solar panel with triple junction solar cells for space applications. The system is radiation-tolerant and features integrated temperature and sun sensors, as well as an optional gyroscope for ADCS.
The EnduroSat UHF Transceiver II is a half-duplex communication module with on-orbit configurable data rates and security based on the Advanced Encryption Standard (AES)-128. The system can be configured for amateur or commercial frequencies and features 2GFSK modulation as standard, with several others supported.
The EnduroSat Onboard Computer is a flight-proven OBC system with ARM Cortex M4/M7 processor of frequency rates up to 180 MHz and 216 MHz respectively. The system also features program memory, a wide array of integrated sensors and connectors, and ProtoBoard. The ProtoBoard simplifies access to main power and communications thus enabling a rapid payload integration. The system satisfies the CubeSat standards.
The EnduroSat 1U Cubesat solar panel X/Y is a solar panel with 2 CESI Solar cells of type CTJ30, suitable for 1U CubeSats. The component is also compatible with 3U and 6U structures of EnduroSat. The temperature sensor and sun sensor are placed on the top surface and the magnetorquer and gyroscope are placed within the solar panel. The network of sensors and magnetorquer can be connected to the Attitude Determination and Control System (ADCS) on the PCB.
The EnduroSat 1U Solar Panel Z is a solar panel consisting of integrated sensors, two triple junction solar cells with flight heritage. The system is designed to be radiation and temperature resilient system and is compatible with many UHF antennas.
The EnduroSat 3U Deployable Solar Array is a deployable solar array equipped with 1 fixed plus 1 deployable panels of 14 triple junction solar cells in total. The system complies with the CubeSat standard and is qualified for LEO and GEO under ESA Standard ECSS E ST20-08C.
The EnduroSat 3U platform is a CubeSat Bus suitable of supporting up to 1.5U (1.5 kg) payloads of nanosatellite with integrated Attitude Determination and Control System (ADCS) and payload integration support.
The EnduroSat 6U Solar Panel is a CubeSat solar panel with triple junction solar cells, integrated temperature and sun sensors, for space applications such as scientific research, Earth Observation (EO), Internet of Things (IoT), communications, and In-orbit Demonstration/Verification (IOD/V). Multiple panels can be connected in series or in parallel configurations.
The EnduroSat EPS - Power Module (Incl. Battery Pack) is an Electrical Power System with flight heritage including ISS-level requirements. and is fully compliant with the CubeSat standard.
The EnduroSat EPS - Power Module I PLUS (incl. 2X Battery packs) is an Electrical Power System with 2x the battery capacity of EPS I. The system is fully compliant with the CubeSat standard and has flight heritage, including meeting the ISS-level requirements.
The EnduroSat Electric Power System II (EPS II) is Electrical Power System to support payloads with high power requirements. The system has multiple outputs with high power efficiency and it is fully compliant with the CubeSat standard.
The EnduroSat S-Band Antenna Commercial is a S-band antenna featuring wide beam, high gain and stacked patch with two feeding points allowing the usage of either LHCP or RHCP. The circularly polarized antenna complies with the CubeSat standard and is designed to be mounted on the Z side of a CubeSat structure.
The EnduroSat S-Band Antenna ISM is an S-band antenna that is adaptable and can be mounted on any side of a CubeSat structure featuring wide beam, high gain, left-hand circularly polarized (LHCP) antenna. The circularly polarized antenna complies with the CubeSat standard.
The EnduroSat S-Band Receiver is an S-band receiver that supports high speed transmission, various data interface and modulation schemes. The system is compliant with CubeSat standard, DVB-S2/S2X and CCSDS.
The EnduroSat S-band transmitter is an S-band transmitter operating in either commercial (2200 – 2290 MHz) or amateur (2400 - 2450 MHz) frequency band suitable for CubeSat or nanosat LEO missions. Idle and transmit are two modes of operation with the option of real-time change of transmission parameters such as central frequency, output power, and symbol rate.
The EnduroSat UHF Antenna III is an antenna with circular polarization, designed to mount on the Z side of a CubeSat structure and deployable by EnduroSat's UHF Transceiver or OBC (Onboard Computer). The system is compatible with EnduroSat's 1U Solar Panel Z. The radiation rods feature a triple redundancy deployment mechanism.
The EnduroSat X-band 2x2 Patch Array Antenna is an X-band antenna with right-hand circularly polarized patch. The X-band antenna uses four patches for shaping the beam to increase the gain. Its low mass and form-factor allow easy mounting on any side of different CubeSat structures.
The EnduroSat X-band 4x4 Patch Array Antenna is an X-band antenna with right-hand circularly polarized patch. The X-band antenna uses sixteen patches for shaping the beam to increase the gain. Mounting can be done on X/Y side of a satellite structure in compliance with the CubeSat standard.
The Endurosat X-band Single Patch Antenna is a right hand circularly polarized antenna. The antenna is designed to have low mass and small form-factor, which makes it easily integrated on different satellite structures. It can also be integrated with other devices on the surface of the satellite.
The EnduroSat X-Band transmitter is an X-band transmitter operating suitable CubeSat or nanosat LEO missions. Idle and transmit are two modes of operation with the option of real-time change of transmission parameters such as central frequency, output power, symbol rate. The system is compliant with the CubeSat standard, DVB-S2 ETSI EN 302 307 standard, and CCSDS.
The EnduroSat 1.5U Cubesat structure is a CubeSat structure that provides a safe environment for the payload and sub-systems during all phases of the mission. The CubeSat structure is modular with 3 types of elements (top, bottom, and legs). The structure also features integrated kill switches and 2 separation springs.
The EnduroSat 1U Cubesat structure is a CubeSat structure that provides a safe environment for the payload and sub-systems during all phases of the mission. The CubeSat structure is modular with 3 elements (top, bottom, and legs) that can be adapted as needed - for instance, a 1U Structure can be converted to a 1.5U structure by changing only the leg elements.
The EnduroSat Cubesat 3U structure II is a CubeSat structure that provides safe environment for the payload and sub-systems during all phases of the mission. The structure also features integrated kill switches and 2 separation springs. The structure is compliant with CubeSat standards.
The EnduroSat Cubesat 6U structure is a CubeSat structure that provides safe environment for the payload and sub-systems during all phases of the mission. The structure is compliant with the CubeSat standards. The CubeSat structure comprises of four main elements: bottom, top, side and ring. The ring element enables stacking of the sub-system and can be customized.
The EnduroSat 1.5U CubeSat Solar Panel is a solar panel consisting of 3 CESI Solar cells of type CTJ30 and PCB with an integrated network sensors and an optional magnetorquer. The PCB can be interfaced to an Attitude Determination and Control System (ADCS) and also enables connection of multiple solar panels in series or parallel configuration.
The EnduroSat 1.5U Platform is a CubeSat platform with ability to support 1U form factor of commercial and scientific payloads. The fully integrated nanosatellite is available with EnduroSat Attitude Determination and Control System (ADCS) and complete payload integration support.
The EnduroSat 1U Platform is a CubeSat platform with ability to support 450g of commercial and scientific payloads. The fully integrated nanosatellite is available with EnduroSat Attitude Determination and Control System (ADCS) and complete payload integration support.
The EnduroSat 3U CubeSat Solar Panel is a solar panel consisting of 7 CESI Solar cells of type CTJ30, suitable for 3U CubeSats with flight heritage. The PCB of the solar panel is integrated with a network of sensors and magnetorquer, and can be interfaced to an Attitude Determination and Control System (ADCS). The PCB also allows connection of multiple solar panels in series or parallel configuration.
The EnduroSat JIG - Ground Support Equipment is a mechanical support for vertical or horizontal satellite assembly of 1U, 1.5U, 2U, and 3U CubeSat. The EnduroSat JIG comprises of five modular component parts and is highly configurable. For instance, the system can also be configured as a case for protecting the CubeSat during the storage and transportation.
Hywel: Hello everybody. I’m your host, Hywel Curtis and I’d like to welcome you to ‘The Space Industry’ by satsearch, where we share stories about the companies taking us into orbit. In this podcast, we delve into the opinions and expertise of the people behind the commercial space organizations of today who could become the household names of tomorrow.
Before we get started with the episode, remember, you can find out more information about the suppliers, products, and innovations that are mentioned in this discussion on the global marketplace for space at satsearch.com.
Hello, and welcome to the episode today. I’m joined by Victor Danchev, Chief Technology Officer at satsearch member EnduroSat. EnduroSat is a nanosatellite manufacturer and operator with headquarters in Bulgaria.
The company has quickly built quite a strong brand in the space sector since being founded in 2015 and has worked with customers all around the world. Today, we’re going to talk a little bit about how to solve some of the common integration and operational challenges for shared and dedicated satellite missions.
But first Victor. Hello and welcome to ‘The Space Industry’ podcast. Thanks for spending time with us today.
Victor: Hello Hywel, Nice to meet you and for the opportunity.
Hywel: Okay. Let’s get into the technical information. We still live in a world where planning for payload interfaces is done in quite a non-standardized way.
In some cases with the CAN, UART, I2C, RS485, all of these different hardware interfaces, and then with even more custom protocols on top. In your view, is standardization a good thing or a bad thing?
Victor: In my view, standardization is always a knife with two edges. On the one side, it’s really nice when we have something like the USB. When you think about it, people who are users of a PC, they never think about USB and they never think is my USB stick going to be okay for this computer or that computer. All computers that have the USB, they support it. And on one side, standardization is awesome because of this, but on the other side, it also slows down progress.
So the way that I see it, if you standardize too much, you are constraining and leaving people less room to do some innovations and to optimize in some way. If you go the other way, it’s the extreme that we have right now in the space sector, which is almost nothing is standardized. There’s so many protocols, probably every payload provider out there and every supply provider out there has their own.
And at some point, any integration is not just sticking areas be it in the PC, but it’s writing all the drivers from scratch. So there is pros and cons, but definitely a situation where you’re in one of the two extremes is always negative for one reason or another. And I think in general, what I’ve seen is that most standardizations, they come up when someone has become really tired of having to customize all the time and when they just decide, oh, I’m just going to take all of this and I’m going to make it into something really compatible.
But guess what? Usually the person who starts this or the company starts this, they’re not the only one. Usually a lot of these are flowing around. So definitely some form of standardization is good. Being flexible is good. And in the end, it’s a trade-off between being able to have more flexibility on the payload side and being able to be really optimized and focussed.
Hywel: Is there an impact on cost and timings in terms of the engineering, if you spend time on different routes, standardized or not standardized?
Victor: There is a lot of difference because if you try to be one key that fits all locks usually means that there’s going to be a lot of overhead on top of you. So if you try to support everything all the time, it really puts a lot of difficulty on a system.
And the way that we approach this at EnduroSat is that we have set up on the hardware side what we consider to be really needed by 95% of the market. We’re seeing most commonly in the market and what most people are looking into. And then on the software side, we try to be as flexible as possible because the truth is that we live in a world where hardware change is not so necessary if you have the right software running on top.
So this is something that we’ve learned and tried to use and to impact our customers by giving them something simple and something easy to integrate.
Hywel: And obviously the teams building payloads and companies building payloads are looking to work seamlessly with platform providers. You provide satellite services for shared and dedicated missions. What do you do at the company to make sure that payload teams can work seamlessly with you and remotely, which has been such a challenge over the last couple of years?
Victor: Regarding the actual integration, one of the things that we have undergone in the last year is we have launched our protocol that is called SPS-1, which is really made to simplify the customer’s life.
So one thing that it does is it allows you to automatically generate the full set of drivers from our platform to a payload by describing the functions of that payload in an ideal, in an interface design language. So a customer at this point, as long as they integrate this protocol on the very basic level with their payload, and we provide libraries for the most common operating systems like bare metals or RTOS, like Linux versions.
And as long as they integrate this, they don’t have to write from scratch all the functions of their payload and to give them to us and to lose literally in some cases months to try to be able to use their functionality and to try to use their commands. What they need to do is just describe in a very simple file, these interfaces. And then the full driver on top is automatically generated so that you literally send us a file. You integrate this very basic layers of the protocol. And as soon as we plug this file into our system, you get off the shelf integration with the platform and you get off the shelf integration with the graphical user interface that we have for it.
So you literally can command your payload from the graphic user interface we give for our platform, which in our review and in the feedback we’ve obtained so far is really a time saver. Because in most cases, the customer needs to spend months developing something like this themselves, which is not always compatible with what the platform provider does. And it can take an even longer time to integrate it.
Hywel: Testing and qualification is so important though, in that process. So in the system that we’ve just described with such protocol automation, how do you do tests such as hardware in loop, software in loop or AIT. How do they work in this environment?
Victor: In the shared sat context, what we do is we expose a flat sat. Basically a satellite assembled on the ground for the purpose of testing. We expose a remote connection to it for our customers, and we integrate their payloads in the same hardware configuration in which they will actually fly. We don’t really focus on emulating the satellite because the assistant like this, you always miss something if you try to emulate it all, fully on the software level, but we actually connect the real hardware or equivalent hardware, like the one which is going to fly with an engineering model of the customer payload, or simply expose the payload remotely to it. And the customer is able to connect to it and to literally play with how they would operate their payload.
And one thing that we do there is we introduced this whole system to a hardware in the loop simulation, which is integrating it the way that it’s going to be in space or things like the ADCS and the orbital position. It’s simulating what the different sensors are going to experience so that we can even play on the operational modes.
So we can simulate situations where the satellite is tumbling. What the sensors are going to measure, what the temperature is going to be. Of course, measurements of the sensors really give a complete end-to-end simulation of the system in order to track any ambiguities in the operational modes, in any situations where this is not going to be the way that they’re formulated is not going to be optimal or going to be dangerous so we can correct them.
Hywel: Do you have a sense of net effect on engineering time and costs, and even lead time for systems are with GUI based interfaces for remote integration and testing, like you just explained?
Victor: One estimate we have is from one of our customers that is flying a payload computer. They have their own device for performing high speed computations on the satellite and processing data on the satellite.
And they’re based on a Linux system. And one of our estimates for how much time was spared is literally in their case, they had about three days from getting the driver and integrating it in their device and being able to actually call functions, which are integrated in our onboard computer. And to send files to their own computer, to execute call on their own computer.
This literally something which would have normally taken months as opposed to a few days. Now this is not always going to be the case. Of course, it depends a lot, in this case, we had the driver for the exact architecture of this device, but the point is that even with the full adaptation needed to modify the protocol to a different architecture, We are looking at weeks as opposed to months.
So at least a few times fold the decrease in integration. In terms of ease of use, something that we’ve noticed is that, especially with some of our academia and agency customers, in many cases, they have a lot of equipment available to them in universities and large agencies, of course, but especially for smaller startup companies, this may not always be the case.
They may not have the most expensive spectrum analyzers, or they may not be able to have the full set of equipment they need to test something like a power system. And when delivering complete platforms, the benefit of this GUI approach is that you don’t need additional ground support equipment.
You really need your computer and the appropriate cable to connect to the satellite. Everything that you need is information from the satellite. Everything that you need to measure is already provided there. So it really saves a lot of time when it comes to having the full AIT performed, especially when you’re a startup, because things that would normally take you a lot of specialized equipment, a lot of effort and costs can be done really quickly and easily.
Hywel: What about teams and companies that are developing payloads that have an element of proprietary technology that they really want to protect. And they are most likely looking for privacy while developing the payloads and AIT both on the ground and while operating the system in space, because you’ve discussed, the systems with a lot of remote access and sharing.
How do you address the issues of privacy or payload, operation and data protection? And also as a bit of a follow-up to that, does this work differently for shared satellite missions versus dedicated satellites?
Victor: That’s a great question. It’s one of the things that we always start with, especially with commercial customers. The full system, the way that we have designed it has several layers of encryption. The most important one when we’re actually in flight is the encryption on top of the RF channel. So any data that the customer wants to get to their payload or get down from their payload, goes through a fully encrypted channel.
And on the ground immediately after it’s dumped on the physical ground station, it gets sent to a cloud account, which is also fully encrypted. It’s end to end encrypted from the moment that the customer wants to send data to the moment they receive it. And this thing is just our encryption. But the customer can actually encrypt their data on top without us having to understand it.
So a payload that’s integrated in our shared satellite platform or in a dedicated platform, doesn’t matter. It can inherently encrypt any data which it transmits or so uplinks or downlinks. I’ll give you an example. If you’re doing sensitive information, if you don’t want your data telemetry to be understood by the platform provider, even though you have all of these assurances, if you want to be absolutely sure that there is no physical way, or if you have images that you really need to encrypt, what you can do is any such data stream that comes out of your device, you can already encrypt it in your device. So we don’t need to know what the data is when you transfer it.
So we’re acting like transparent provider of data channels up and down to the payload. Of course, to command the payload we must be able to know its functionality in this type of idea that I discussed. We must know what the payload can do, but we don’t have to get any of its information. So you can just send commands to it.
And then as soon as any data is generated and it needs to be downlinks, it can be fully encrypted by the customer. So not only they can decrypt it on the ground, in their secure account. This is something that I believe we’re going to be seeing more and more in the future happening. The good news about what I mentioned as a ground architecture for the AIT and the remote integration is that, we’re actually using the exact same architecture we use for the in-orbit operations, as the one we use for this type of testing.
In fact, we even use UHF or S band, depending on the type of payload channel. So the flatsat is not actually connected directly to a network it’s RF device, S band or UHF/VHF, is connected to an RF cable and attenuator to what is the ground station computer let’s say. And on the ground, when we do this kind of testing the system level, testing the integration tests, we actually do it with an RF connection. We don’t do it by having the full satellite connected over a cable. We do it in the same way that you would do it in space with the only difference that the satellite is on a table and you have an attenuator instead of having the satellite in space and the free space attenuating the signal.
So they can benefit from exactly the same reliability and exactly the same encryption, so that even if a rogue employee goes through to take out their payload from the table, only they have the encryption in their own premise. And this is not physically possible to touched.
Hywel: You touched briefly on the future there, the sort of approaches that you were expecting to be seen in terms of ensuring the privacy of the data, et cetera. I wonder if you could just explain a little bit about, just as a final follow-up, how you see the future of integration and operational challenges such as those we’ve discussed today in general, evolving in the next three to five years?
Victor: I think that the smallsat sector is maturing really quickly. One of the things that we have noticed is that two, three years ago, encryption was very rare in the subsystems. And now a lot of customers want it. A few years ago, they were considered really still on the toy level. And now, I don’t think anyone is doubtful that you can have hundreds of these satellites generating a tremendous amount of data and actually doing better than one large satellite for certain applications.
So I see a lot of maturity and I think that this maturity is going to go two ways. On one side, there is the people who try to approach small satellite segment like classical satellite segment, and they try to push all the regulations and all the, I would say bureaucracy of a large satellite segment, which I don’t think is going to work because you’re just pushing complexity in a place which is good because there is no such complexity.
I think such companies that try to push too much regulation and too much classical satellite know-how in small satellite, they’re just going to make one generation of nice satellites and then be scared to innovate like it is with the bigger satellites, but the alternative is to really always stay ahead from the edge of what’s possible.
So I think that the integration challenges are mostly going to be related to having more digital twins, to having more places to actually run and test, to have really completely remote satellites. When you think about it, even if you have subsystems in different countries to be able to integrate them completely remotely and to test that this thing works as a single system and to really show how it would work at some point in space, even if you don’t have them physically.
And in the current era where I would say we are decentralized and cloud oriented, companies that ride this wave of digitalization of technology, I think are going to really benefit tremendously on the long run and produce the best.
Hywel: Brilliant. That’s a vision that would really democratize and open up the space industry across the world by removing the barriers during integration that can exist.
So thank you, Victor. That’s great. I think that’s a good place to wrap up. Some really interesting insights there for our audience into how different integration mission design challenges have been solved today, which is great. Thank you very much for spending time with ‘The Space Industry’ podcast community.
Victor: Thank you!
Hywel: And to all our listeners out there, thank you very much for listening and hope you enjoyed the episode too. Remember that you can find out more about EnduroSat on satsearch.com and we’ll share the links in the show notes to the company’s pages. On the platform, you can find out further technical details about their company’s portfolio and make requests for technical information and documents, ask for introductions to the company, quotes or whatever else you might need for your trade study or procurement purposes.
Thank you for listening to this episode of ‘The Space Industry’ by satsearch. I hope you enjoyed today’s story about one of the companies taking us into orbit.
We’ll be back soon with more in-depth behind the scenes insights from private space businesses.
In the meantime, you can go to satsearch.com for more information on the space industry today, or find us on social media if you have any questions or comments. To stay up to date, please subscribe to our weekly newsletter and you can also get each podcast on demand on iTunes, Spotify, the Google Play Store, or whichever podcast service you typically use.