Anatomy of CubeSat Telemetry
Published on February 13th, 2020
Have you ever wondered how PRO satellites organize their telemetry. Want to get some inspiration and avoid troubles later when your CubeSat is up there? Join me on the walkthrough of the basic of space telemetry design.
Just after launch, waiting for first packets
Tensions are soaring. Your team has gathered in the Mission Control room.
The air is filled with high expectations, worries and thoughts shooting in all different directions.
It’s about an hour after your CubeSat has been launched on the polar orbit. You’re impatiently awaiting the first telemetry, first beeps, first whatever from your satellite. The first proof…
Last 3 years were filled with sleepless nights typing code and reviewing design drawings. And now it is the ultimate moment. Will it work?
Tick, tick, tick, tick…
Almost un-recognizable chirping appears at first. Is that it? Do we have a signal?
Console cursor slowly starts moving.
YEEESSSSS…!!!! YES…!!!! we got signal. “WEeee MADE IIIIIIT !!!!!!!”. Emotions peaks…
“Systems are OK !!!!!!!!! “ someone shouts…
Whole team bursts into tears, laugh, hugging, smiling, congratulations…
The day after…
After a late-night party, celebration and some nice e-mails, it is a time to roll up your sleeves and to start analyzing the first telemetry from your CubeSat.
Slowly, the focus starts to build again: What is inside those data?
The raw byte streams
Because your communication protocol designer and ground station developer were careful, they store both: the raw data streams received and the processed data.
Inspiration for data organization came from here.
What’s inside the raw data/telemetry streams?
Well, except some noise, you can find two main things there: #1 data frames (a.k.a. SDU = Service Data Unit) and #2 delimiters of the frames, separating consecutive frames from each other.
There are different algorithms used for delimiting consecutive frames. Some commonly used are COBS and SLIP. The CCSDS, which defines space communication protocols, defines its own bit patterns for frame separation called ASM (= Attached Sync Marker).
Telemetry is typically transmitted in one of two ways. It is either a fixed sequence of bytes with defined structure, or in more complex case, it is wrapped into packets and frames.
The first case, when telemetry is reported as a fixed structure of values is useful in case when simple and high-speed real-time data are reported. No complex data, no different data streams.
Good example of simpler telemetry are small launcher applications: just plain simple structure of basic data (e.g. speed, altitude and couple of other parameters), reported periodically at high speed during the boost phase.
The more complex example, when telemetry is wrapped into packets and frames is used when routing, addressing and other protocol features are needed. I’ll be happy to share it with you, but that deserves its own blog post.
It is a Babylon of packet standards out there…
Finally, the telemetry data themselves
There are indeed more features to think about, but two basic which you want to consider early in your design are timestamping and addressing.
Timestamping your telemetry has a lot to do with the dynamics of how telemetry is reported all the way from sensor up there on the orbit down to the operator’s terminal in your Ground Station. More on that below…
Addressing is something that will have great impact on how you design your data communication paths. From subsystems, to OBC on-board, to radio to Ground Station to the right database.
In simplest case, you’ll only have two addresses: the satellite and the ground station. In more complex scenarios, you’ll want to consider how to address packet so it on-demand goes via backup databus instead of main databus from your on-board radio to OBC.
You simply need a good way to identify which system to reach a which way to go there.
Structure of the telemetry data units
Here we go. The main topic.
You have probably heard about the triplet – header, data, footer. I won’t talk about obvious again.
Perhaps more interesting from this topic are factors like ratio of header and data size. Just for fun and profit… try to calculate this ratio for your COM protocol.
Telemetry data themselves, typically include so called secondary header, which atop of generic packet header identifies nature of the reported telemetry.
ECSS, the main standardization body of Space-related engineering in Europe, identifies telemetry by its PUS service and subservice. Service and subservice are reported in the secondary header, preceding the telemetry values themselves.
For example, PUS Service 3 is related to reporting housekeeping and diagnostic data. Subservice 25 deals with report of the measured data themselves. If you receive telemetry TM [3,25] (as your code recognized from secondary header) you know what structure of telemetry values to expect.
Dynamic of telemetry transfer
As I promised you earlier in this blog post…
This has a lot to do with the orbit of your satellite and the communication window. The transfer rates along the segments of the path from in-orbit sensor to the terminal in Ground Station will differ.
Your sensors are indeed able to measure data at high rates…
Considering that average CubeSat communication session on polar orbit lasts anywhere between 1 and 10 minutes (depending on frequency), you’ll want to build a system of buffers to store, process and prioritize telemetry.
Smart timestamping comes handy here, because your telemetry will probably sit some time in the RAM buffers before you’ll have a chance to transmit it down to your Ground Station.
1:30 AM – deep night, blacker than black…
Ground software developer is pounding keyboard. Given the amount of data received from your CubeSat today it becomes crystal clear that an automatic telemetry parsing is needed.
Higher-level data products L4 – L5 are needed to better understand what’s going on up there. NASA helps us here.
State-of-the-art code editor is struggling to show autocompletion pop-ups at the speed of developer’s thoughts and keystrokes. The main reference – the ICD document with your protocol description is finally getting its deserved attention.
If you have read until here... spend a few more minutes with this thought:
A good protocol and telemetry structure along with its detailed description (ICD) will save a lot of time and will make a lot of people happy. Including your Ground Station software developer. At the end its 1:30 AM… he also wants some sleep.
-- With all professional regards,