A CubeSat communication subsystem needs to provide a method of transferring data between a control team on the earth and an orbiting satellite. The system can be divided into two overlapping blocks, the ground station subsystem, and the on-satellite subsystem. This article is from the perspective of the on-satellite communication subsystem.

The SEDSAT-2 “comms” team, who develop the on-satellite component of the communication subsystem for the SEDSAT-2 CubeSat, are a group of mainly electronic engineering/computer science students, with a representation from mechanical engineering too. Currently, we are seven people strong, with three located in Manila, three at separate locations in India, and one person in the UK. In a distributed environment such as this, it is quite a challenge for a team who are new to a technical topic such as communication system design, to work together to figure out how to attack the problem. The solution to this, as far as we have figured out, is careful planning, breaking down problems into independent work-packages, and regular team meetings where we can discuss our work and decide what we need to do next. Underpinning this are the technical tools which facilitate our process; wiki’s, for sharing and archiving research ideas, Instant Messaging software, for live team communication, and revision control software, to provide a shared filespace accessible on each team members computer.

So perhaps you are wondering what is involved in a satellite communication subsystem. The most obvious problem is the distance we have to transmit over. We expect our satellite to be in a low-earth orbit, so typically the distance from our ground station to our satellite will be around 2000km, although this can rise to 3000km and drop, on rare occasions, to 700km. A second, connected problem, is that the satellite is continually moving relative to the ground station. This in-deed provides the ground station team with some problems, as they need to keep adjusting where they point their antenna in order to find the satellite, but for the on-board satellite communication subsystem the problem is more fundamental. As we only expect to have one or perhaps two ground stations, and the ground station can only contact the satellite when the satellite is above the ground stations horizon, most of the time it turns out that the satellite is below the horizon at our ground stations, so there can be no communication! This gives us our first parameters: some orbital modelling with the Orbitron software shows that in a typical 24 hour period, a single ground station may only see the satellite once for about 20 minutes, and with perhaps two or three other “passes” of 1 minute of so. In this 20 minute per day “window”, all of the data we want to send from the satellite to the ground station must be transmitted, and any control information we want to send from the ground to the satellite must also be transmitted.

We expect the payload team to generate around 1MB of data each day, so in order to transmit all of this in our 20 minute window, our comms subsystem must be able to transmit at more than 6990bit/s. To allow for some overhead, we have decided to target a transmission rate of 9600bit/s. This is our first major specification!

Now, back to the distance problem from earlier. We are typically 2000km from the ground station but because we get all our power from solar panels on the satellite (which isn’t a huge amount), we can only afford an on-satellite transmit power which is similar to that of a mobile phone. But our distance is about 1000 times greater than what a typical mobile phone signal needs to travel, so we’ve got a problem. There are ways to overcome this problem, but they involve a big antenna on the satellite, and this doesn’t work on a CubeSat, as we only have a little cube (10cm by 10cm by 10cm), so no room for a big antenna. So we decided to turn this distance problem over to the ground station team – they don’t have any size limits (well, within reason), or any power limits so they are much better placed to design a huge directional antenna, or to commandeer the Arecibo radio telescope in South America in a black-op style raid, whichever they feel is most appropriate. This turns out to be a fairly effective strategy (shifting communication problems to Ground, not black-op raids) in general, for various communication problems, and is usually termed a “System Design” decision – if a problem can be better solved elsewhere in the system, then do it!

So far, we have defined our basic system performance specification, and we have decided not to worry about our limited transmitter power. Next, we must start thinking about how the communication subsystem will work.

A signal transmitted from our satellite has to travel a huge distance to get to the ground station, and on its way it has to go through the earths atmosphere. Various parts of the earths atmosphere have effects on our radio signal, causing distortion. Also, while the ground station should be able to pick up our satellite signal, it will also pick up lots of other interference from things such as lawn mowers, powerlines, lightning strikes and automotive engines. When all this is put together, we find that our received signal doesn’t look particularly like our transmitted signal, and that there is a chance that ground station receiver will not be able to properly decode the received signal. The result is that some of the data we transmit will not be received correctly.

We need a way to overcome this problem but luckily the answer is well established in the protocols which make up the internet; an automatic retransmission system. In this system, data that we want to transmit is broken into chunks or “packets”. Our satellite can start transmitting packets and after the ground station has received each packet correctly, it sends an acknowledgement to the satellite, to let it know that the packet was received. If however the ground station detects an error, it sends a “not-acknowledged” to the satellite, to let it know to retransmit the packet. We’ve taken this basic structure and added a few more features and have given it the name SEDSAT-2 Reliable Transmission Protocol. All companies and projects have their own acronyms and we at SEDSAT-2 don’t want to be left behind in this regard, so the acronym for our transmission protocol is: SRTP. A full technical protocol specification for SRTP will be made available on our wiki page soon, so if you’re interested in more information, that will be the place to look.

In summary, we have been developing a communication system which provides a reasonable data rate, works with intermittent communication windows, is tolerant of communication errors and emphasises a system level design approach where we simplify the satellite where possible by pushing as many problems to the ground station as possible. Besides making available the increased resources available to the ground, this latter approach also means that there is less to go wrong on the satellite – as once the satellite is launched, it can not be debugged or fixed, so it absolutely has to work. With the ground station however, if there is a problem after launch then it isn’t the end of the world as we can still debug and fix the problem.

I hope this article gave you an (very rough) idea of what the communications team is working on. If you’d like to find out more, take a look at our wiki page[1], or get in touch with the team (contact details are on the wiki!) with any questions you’d like answered. And if you would be interested in joining the SEDSAT-2 team to work on the communication or ground subsystems, take a look at the vacancies on the SEDSAT-2 recruitment page[2], we’re always on the look out for motivated people who have an interest in Space, who want to do something challenging, exciting and unique.

[1] http://wiki.seds.org/index.php/SEDSAT-2_Communications

[2] http://wiki.seds.org/index.php/SEDSAT-2_Team_Application