Free cheat sheet to kickstart your CubeSat communication design and avoid troubles on-orbit
Published on 31st of January, 2020
In this article you’ll get a quick 30000 feet view on designing space communication protocol for a CubeSat mission. I’ll show you a small cheat sheet to help you quickly build a list of important things to consider when it comes to your CubeSat communication protocol.
A Quick Warm-up
So, now your CubeSat hardware is nearly ready. The radio and link capabilities are getting clearer.
Do you use half-duplex or full duplex channels?
How many times a day you have a chance to communicate with your satellite?
What type of data you will download?
These questions (and few others) will a have great impact on the way you’ll approach the design of your communication protocol.
A word of warning before we dive into it.
Please, don’t be one of those who fall into the trap of “Oh, we just need a super-simple protocol – one byte up, one-byte response.”
Your mission is well worth an average family house (or two). Don’t underestimate design of your communication. No communication, no mission. Sure, there are exceptions to this rule, but you probably don’t fall into that category.
Trust me, staring at the incoming stream of secondary data which you could happily live without, while important information about failing power system sits stubbornly in flash memory up there on the orbit is not a good feeling.
Well, you got the point…
Enough. Let’s dive into tips and tricks.
Designing data flows
When it comes to designing data flows, mission designers want to be a bit inventive. Trying to foresee all possible scenarios of systems interactions and unexpected events is not an easy task.
How to prevent a flood of telemetry from a subsystem?
How to prioritize telemetry, so you get the most important data out before the battery gives up?
What is the definition of the important data in your mission?
You want to start designing communication by thorough interrogation of your system engineer. There is no other word for it. You really want to be as precise in the talks as possible. Subtle details which you omit now may trigger huge reworks later.
You may find that the COM protocol is given by the customer’s requirements. You may also find that your radios are only half-duplex (i.e. only capable of communication one-way at the time). You’ll probably find many other things and have a few “a-ha” moments. The #1 reason why projects fail is the lack of communication.
Ask especially about (out little cheat sheet):
#1: A communication window (e.g. how long you’ll be able to communicate up or down).
#2: Type of mission data. Amount, type, meta-data, validation, security, etc.
#3: Structure of on-board subsystems and their commanding / reporting.
#4: Failure and recovery scenarios.
#5: Complexity and functions of each subsystem.
Without wasting your time, here is your secret target behind each of those five questions. Loosely translated, the five points above can be re-written as:
#1: Length of COM window = amount of data transmitted, needed data buffers, data timestamping and prioritization features of your protocol and software.
#2: Type of mission data = encoding, encryption and validation features on both ends.
#3: Structure of on-board subsystems = routing and source/destination identification for data units.
#4: Failure and recovery scenarios = communication modes.
#5: Complexity and functions of subsystems = ICD (Interface Control Document). Ufff, yes… we’re going to put somethings down on the paper.
There are more points to talk about. But, the five points listed above give you a pretty good head start compared to any average team doing software communication design.
You have probably though about all these features at some point. But, having a small cheat sheet at hand gives you a good starting point and saves you a bit of time.
A bonus point: Your mission is changing with every orbit
So are changing your communication needs. Here is the point to complement the cheat sheet above – and this is a big one: Do not think about your mission in terms of average-case communication session.
Ok. A bit of a smart-ass sentence. So, I’ll repeat it…
Do not think about your mission in terms of average-case communication session.
Your communication will look differently in the initial phase than during mid-life communication or during failure scenarios. Design for all these phases and you are right on track to a successful mission.
This article really was just a warm-up. A 30000 feet view on some of the major points in designing space communication for your CubeSat mission. More is coming… check our Facebook, LinkedIn or Instagram channel.
Let me know if you find this information interesting or related to your work (or in best case, combination of both).
I’ll be glad to hear about the points in your mission which turned to be THE important things, and which looked like minor stuff not worth the time at the beginning. Let us know.
Stay tuned and give me a feedback. I’ll go into more details on the space communication protocols in the follow-up articles and videos.
-- With all professional regards,