This is Alén Space's blog for nanosatellites and space content. If you want to put your business idea in space and you are interested in the functionalities and potentials of small satellites and CubeSats, this is your place. More information avaliable upon request.

Small Satellites: What Tech Do You Need for Space IoT Services?

Small Satellites: What Tech Do You Need for Space IoT Services?

If you intend to enter the New Space age to offer space IoT services with the help of small satellites, the last thing you want to read is probably an explanation of what IoT (Internet of Things) is, what M2M (Machine to Machine) communications are, or how many millions of connected devices there will be worldwide in 2030. We promise to get to the point and not start from scratch. All of this basic information is available in the hundreds of articles you can already find on IoT and M2M on the Internet.

In this article, we want to clarify some specific doubts you may have about a nanosatellite project to provide IoT services in space:

  • How does a constellation of CubeSats for IoT communications work?
  • What hardware and software equipment will you need to consider to develop this project with Alén Space or any other nanosat provider?
  • What is the function of each of these hardware and software tools?
  • How do the different elements you need to offer space IoT services relate to each other?

All in a detailed way, but without going over the top with technicalities. And we will do so based on the three sections that make up any project related to small satellites: the space segment, the ground segment and the user segment.

The space segment

In short, and as its name suggests, this segment corresponds to the part of the project that is in space: the CubeSat itself or the nanosatellite constellation.

In the space segment we can fundamentally differentiate between two elements: payload and platform. Due to its importance within the project, in this case we are going to refer to a third element, known as On-Board Software, which in a strict sense would be within the platform part. But let's go step by step:

  1. Payload. This is everything that allows us to answer this question: why do we make the nanosatellite? If we talk about IoT, it will be a device that can receive, store and forward the data (TOTEM, in the case of Alén Space, as we will see later). If we think about Earth observation, it would be the camera in charge of capturing the images. And if we were talking about science, it could be a micro-laboratory to do studies outside the Earth with certain technological or biological materials. The options are vast. Each project has its own characteristics, and it is possible to find mixed units with several payloads that coexist in the same nanosat.

    But let's stay on track and refocus on an IoT project. For this function, in Alén Space we have TOTEM, an SDR (Software Defined Radio) platform whose possible configurations include solutions that are already developed and ready to launch for IoT/M2M, ADS-B and Signal Intelligence.

    TOTEM would be the payload in our IoT projects, although it would be possible to incorporate other solutions developed specifically by the customer to fulfil its functions, which consist of receiving, storing and forwarding data. It would therefore be responsible for the communication of the satellite and the IoT service itself.

    Imagine that when the smallsats are already in orbit some kind of reconfiguration has to be done. The reasons can be different. For example, an update of the current communication protocol, a modification in the frequency bands (UHF, S and L are the most common) or a change in the speed of data transfer. In the case of TOTEM, as it is a configurable tool, these adjustments could be made in orbit.

  1. Platform. This is everything in the nanosatellite that allows the payload to fulfil its objective, giving it the necessary electrical and structural support: the on-board computer, external structure (1U, 2U, 3U, 6U...), solar panels, batteries, etc. If the platform works properly, but the payload fails, the nanosatellite loses its raison d'être and becomes space debris orbiting the Earth. And in the opposite case, if the platform does not work as it should, but the payload does, it is orphaned, although there may be correction or mitigation mechanisms depending on the type of error. Therefore, it is essential that the two parts work correctly: platform and payload.
  1. On-Board Software (OBSW). This could be included in the platform section, but due to its importance we are going to analyse it separately. It is the software that allows the operators to manage and control the satellite. If it is of low quality, the control that can be done from the Earth and the solution of problems that may arise in orbit are much more limited. It has a direct influence on the CubeSat's own useful life. In the case of Alén Space, we have an On-Board Software (OBSW) based on the ESA Packet Utilization Standard (PUS), which allows for a meticulous control of the nanosatellite: error detection and repair, recovery system, TOTEM on and off, parameter configuration, antenna control, etc.

Ground segment

The ground segment corresponds to those elements located on the Earth, which are necessary for the control and operation of the satellite. Here we usually differentiate between mission control and ground station, in which we will distinguish dos elements: Ground Segment Software and antenna.

  1. Mission control. You've probably seen a movie with NASA engineers sitting in front of a big screen, each with several monitors on their desk and headphones. That's mission control, in most cases on a much smaller scale, especially when it comes to corporate projects with nanosats. Mission control must have access to ground stations and there must always be at least one. This is the intellectual part of the project, the people in charge of thinking, deciding and planning how the satellites are going to be operated.
  1. Ground station. This is responsible for communication between the operators and CubeSats. In other words, they receive and send the information related to the payload and to the configuration of the satellites. A project may have anywhere between one and 300 ground stations on the whole planet. Depending on this number, it will be able to communicate a greater or lesser number of times with the satellites. One of the most common possibilities is the rental of ground stations in those parts of the planet where it may be necessary. In terms of tools, based on our experience at Alén Space, there are two fundamental ones:
    • Ground Segment Software (GSSW). This is the software used by the operator in the ground segment, which allows them to communicate with the satellite in order to operate it and carry out the mission. In the same way there is a type of software in the space segment (OBSW, as we have seen), there is an equivalent on Earth, which makes it possible to download telemetry, send commands, etc. via a special interface. At Alén Space we have our Ground Segment Software (GSSW) for this purpose, which like OBSW is based on the ESA Packet Utilization Standard (PUS). These are two software tools that have to be compatible, because they will interact with each other.

    • Antenna. In the ground station there must be a physical antenna, which performs a bidirectional function, as it transmits and receives the signal from the smallsats. This will depend on the band in which you work, the power you want to emit or the directives used, although there is a wide range of antennas in different shapes and sizes, from the Yagi type to parabolic antennas in different sizes. As for their location, the less electromagnetic noise around them and the more clear sky the antenna can cover, the better the communication with the satellites will be.

User segment

The third vertex of this triangle is the user segment, which answers this question: who uses the service provided by nanosats?

We have to clearly differentiate between the information related to this segment, which is directly connected to the payload and the service that is going to be provided to an end customer, and the information obtained from the nanosatellite on its own performance, which is managed in the ground segment and which does not have such a direct relationship with the service for which the CubeSats were designed.

There are three elements that have to be taken into account in the user segment:

  1. Sensor or message generator. This is the starting point of the service provided by the company that controls the nanosatellites. The ability to manage the efficiency of processes with sensors is one of the factors that have driven the IoT. We refer to the information or data that is collected or generated at a certain point, with the help of a message generator that may be a sensor, an SMS, a computer, etc. Once again, there is no single valid answer, as there is a wide range of possible alternatives.
  1. M2M/IoT Terminal. So far, we have seen what the smallsat carries (space segment), how it is managed from Earth (ground segment) and how the information that should reach space is obtained (for example, through a sensor in this user segment). But if we do not go one step further, there would not have been any communication for now related to the service intended to be provided through the satellite or the constellation.

    In other words, if this were a real IoT project, for now we would not have given any practical use to the CubeSat payload. Basically, we would have a sensor that has collected a lot of information, but has not transmitted it, and a satellite orbiting the Earth, but without any function to perform.

    In a project consisting of offering IoT services in space that intends to use smallsats, this should involve a device for exchanging short messages with the nanosatellite, which in the case of Alén Space would be our M2M/IoT Terminal. The (mutual) sending of data between this hardware and the nanosatellite payload (TOTEM) makes it possible to fulfil the objective for which the project was developed.

    The M2M/IoT terminal connects directly to the message generator (e.g. a fire sensor), receives this information, transmits it to the satellite and collects its responses, if any. This is a device that is configured to know at what moment the CubeSat is going to pass overhead, in order to be able to exchange information with the payload of the nanosatellite at that precise moment.

  1. Final destination of the information. In order to provide the service for which the project has been designed, the nanosatellite payload receives the data gathered by the message generator and sent by the M2M/IoT terminal. Depending on its programming, from the CubeSat they are transmitted to a ground station (see ground segment section), and from there to the final point where it has been decided that the data will be treated and shown, which may be a cloud service, a company server, a public website, a database, etc.

 

And with this we bring the process to an end. We hope we helped you understand how a constellation of small satellites works to provide space IoT services.

If you want to develop a project of this type, we encourage you to contact our team or find out about the next steps you should take.

In our manual 'Nanosatellites: Ultimate Buyer's Guide to RFP Success' you can find the necessary information to choose a nanosatellite provider with full guarantees.

Featured image: ESA / NASA - A. Gerst

Nueva llamada a la acción

Related posts

Subscribe our monthly newsletter

Nueva llamada a la acción

Recent tweets

Archives