OPS-SAT re-entry

ESA’s OPS-SAT will undergo atmospheric reentry within May—June 2024.

Since launch in 2019, the experimental CubeSat has enabled teams from companies and universities in Europe and around the world to test and validate new innovations in satellite operations that would be too risky to try out on a flagship mission.

Its mission is now coming to an end: the satellite’s altitude is decreasing as it loses the battle against atmospheric drag. OPS-SAT is roughly the size and mass of a piece of aircraft carry-on luggage. So, there are no risks associated with the reentry.

However, it offers a rare chance to gather valuable data.

OPS-SAT is in a unique position because it is still a very capable, functional spacecraft equipped with an ultra-high-frequency (UHF) radio transmitter that uses frequencies accessible to the global radio amateur community.

During the final stages of reentry, atmospheric drag will wrestle control of the satellite away from its team on Earth. But, while high-speed S-band satellite communication will not be possible, OPS-SAT will continue to broadcast telemetry data via its UHF radio in real time. These packets can be detected from the ground even if the tumbling spacecraft is not pointing towards Earth.

“The data that we could obtain from OPS-SAT would be used to calibrate atmosphere models at such low altitudes, where there has so far been little to no data collected. In addition, if we are able to determine the evolution of the attitude of OPS-SAT, we can calibrate the propagation models. All these data will help improve the prediction of the time and location of atmospheric reentries,” says Benjamin Bastida Virgili from ESA’s Space Debris Office.

“To collect this telemetry, we plan to use our own UHF ground station at ESA’s European Space Operations Centre in Germany, and one provided by the Department of Mechanical and Aerospace Engineering at the Sapienza University of Rome,” says David Evans, ESA’s OPS-SAT Space Lab Manager. “But OPS-SAT only passes these ground stations a few times per day, so we won’t be able to gather much data alone.”

“With the support of the global radio amateur community, we could gather data from OPS-SAT over its entire orbit during this final phase.”

It wouldn’t be the first time that the radio amateur community has supported the OPS-SAT mission. In fact, the community was challenged to catch the first signals from the satellite after its launch in 2019 and their continued support was essential during the mission’s difficult LEOP and commissioning phase.

Now, we are calling on that same community five years later to catch OPS-SAT’s final signals. We hope to collect as much data as possible during OPS-SAT’s final days in orbit, for the benefit of the entire space community.

Click here to access the OPS-SAT radio campaign portal. From here, you can register your participation in the project and receive the API key you will need to send us the data that you collect.

You can then use the other links on the portal to download the software for receiving and decoding OPS-SAT’s UHF packets and instructions on its use. The portal also features a leaderboard ranking participants on the number of frames they have provided. At the end of the campaign, the winner will receive an OPS-SAT mission T-shirt, calendar and a signed certificate.

source: Help us catch OPS-SAT’s final signals! – Rocket Science


Please let me know if regular reception send to Satnogs network will be used also by ESA, or only the packets using the registration gateway.



While the OPS-SAT team has provided links to numerous GNU Radio flowgraphs, I wanted to share a very basic .GRC file to feed properly formatted payloads to their GUI App as well as, optionally:

.local .KSS file

… with the source either being an AUDIO file that you might have recorded (sample file also at my URL) or ‘live’ FM audio from the SDR of your choice. My flowgraph is already setup for GQRX because that’s what I use, but if you have another method of connecting audio from your favorite SDR app to GNU Radio, you’ll already know how to add that to this framework.

My files are at:


… and the OPS-Sat GUI app (+ other info) is available at:




Well, the 0025utc pass over the Eastern U.S. had a max EL here of 44°, but no downlink was seen.

Does anyone know if OPS-SAT is only active in daylight, or only over certain parts of the world?


Thanks for sharing the information Scott, with some small changes and updates also working with GNUradio 3.10

Also tested the SatNOGS audio replay. I guess that isn’t optimal for the ESA group because the time and date will be wrong.


Excellent - glad that was useful!

My question was answered - N6RFM (and others) got decodes on tonight’s pass over the U.S.

Great news!


For those that want to use the ESA AppImage and gr_satellites:

This is a replay from SatNOGS Network - Observation 9468309

gr_satellites OPS-SAT --wavfile 9468309.wav --samp_rate 48e3 --throttle --start_time 2024-05-03T19:28:12 --zmq_pub tcp://

I got CRC Ok False messages and I am not sure if this is obs related or gr_satellites command line.

The time and date used by this cli is not used by the AppImage so it will forward time data stamps based on when this manual replay was running.


A replay, using the GNURadio grc file provided by Scott has no CRC errors, the only thing I can see that is a difference is the PDU to Tagged Stream block and I am not sure if there is a cli option that will have the same result.


Using gr_satellites, all raw data packets start by “07090702000b7472616e736d6974746572020010396b362046534b20646f776e6c696e6b090702000972735f6572726f72730300000000060a000000003e0100” which leads to “ERROR Received CSP packet of length 122 bytes - Failed CRC32C!” for a 62 bytes packet.

Got the difference.

While Scott’s flowgraph uses ZMQ PUB Sink, gr_satellites uses ZMQ PUB Message Sink.

I’ve added the block to the flowgraph and checked the output. Same as for using gr_satellites.

In comparison to gr_satellites’s decoders, SoundModem or Direwolf are sometimes better in decoding weak signals.
So I decided to alter K4KDR’s GNURadio flowgraph a little bit to feed it KISS data via TCP from those modems.

OPS-SAT UHF App needs the CSP payload CCSDS descrambled and Reed-Solomon decoded which is done by the block Satellite decoder in K4KDR’s version.
However this block needs audio input. To feed KISS data instead, I followed gr_satellites’s ops_sat_deframer.py and rebuild every necessary single step one by one.

OPS_SAT_fm_Soundmodem_KISS_out.grc.zip (1.6 KB) [GNURadio 3.10]

If SoundModem, use the standard 9k6 Highspeed version, not the special version for OPS-SAT.


Now with more than 16.0 revolutions/day, OPS-SAT is getting in the final stage of its re-orbit. We start counting days for its re-entry and soon we may need to start generating orbital data to track more precisely its orbit.


Yes - the pass here yesterday required a lot of manual tuning to stay on frequency!


1 Like