pistonminer

@[email protected]
571 Followers
137 Following
39 Posts

satcat, but not the NORAD kind 🛰️🐱

hacking video games, space systems, and other rocks that try to think

CTF w/ ENOFLAG

operating BEESAT-1 @ TU Berlin

🏳️‍🌈🏳️‍⚧️

pronounsshe/they
pistonminerFeb 13
Daniel EstévezFeb 13
New blog post: ESCAPADE telemetry. In November I posted about decoding the telemetry of this Mars twin orbiter mission. @pistonminer
did additional reverse-engineering, and I wanted to revisit this and dig deeper in the telemetry. In this post I go over some details of the flight software, including file downlink, logs, and on board scripting. I also find some quaternion data and gyroscope data that are a good match, plus other quaternions that I don't know how to interpret.
Show threadpistonminerJan 2
@hermlon ><
Show threadpistonminerDec 20
@manawyrm mrrrrrow :3
Show threadpistonminerDec 5
@cmax Very odd, thanks for letting me know. I must admit I didn't test under Linux. I did experience some weird behavior related to the Doppler estimator before with the flowgraph getting stuck but didn't manage to track it down. If you find out anything else please let me know!
Show threadpistonminerDec 3

@cmax Hm, I just decoded your I/Q recording myself and it worked fine for me for both channels. The only changes I made were adjusting input_samp_rate and adding an IChar to Complex to adapt to your 8 Msps signed 8-bit file, no change to symbol sync. I'm not sure what the problem could be exactly :/

To triple check, are you definitely running

tubin_sband_decode.py data_cmax_c0.bin data_cmax_c1.bin <output_folder>

with both channel files in one command?

Decode results:
https://drive.google.com/file/d/1xlWhgGM1Ra3im8K-qjkdJlwrBjlCWbeB/view?usp=sharing

Show threadpistonminerDec 3
@cmax Another possibility is that the signal quality of one channel was worse than the other, leading to one channel simply not being decodable. We suspect that the antenna pattern might not be exactly identical between both channels, which may make a difference the further from the main lobe your ground station is, given the satellite points at Berlin while transmitting. Do you have a waterfall plot or something like that perhaps?
Show threadpistonminerDec 3

@cmax Awesome! TUBIN is usually configured to alternate packets between both transmitters which causes the striping if the packets from one transmitter are decoded but the ones from the other aren't.

It's hard to debug without I/Q, but the data files look like they might both be from the same channel, did you switch the "channel" variable in the flowgraph between runs? You need to decode channel 0, then channel 1, then put both data files into tubin_sband_decode.py at the same time in one go.

Show threadpistonminerNov 28

TUBIN will be reentering the atmosphere and burning up in ~2-3 weeks, and we will try to track it and download data for as long as possible during the reentry process. If you have a ground station in Europe capable of receiving on ~2260-2270 MHz and would like to help receive telemetry and images before and during reentry, check out the receiver https://github.com/PistonMiner/hispico-receiver and forum thread https://community.libre.space/t/tubin-tubsat-27-re-entry/13998/

If you decode anything, please feel free to tag me :)

GitHub - PistonMiner/hispico-receiver: Software receiver for the HiSPiCO transmitter

Software receiver for the HiSPiCO transmitter. Contribute to PistonMiner/hispico-receiver development by creating an account on GitHub.

GitHub
pistonminerNov 28

The TUBIN satellite takes infrared pictures and transmits them on S-band using the "HiSPiCO" transmitter. Decoding this without a matching hardware receiver was hindered by the use of an undocumented forward error correction scheme, making it inaccessible to radio amateurs. Using a "known-plaintext" pair of I/Q data and decoded data provided by TU Berlin, I've managed to reverse engineer the FEC and implemented a software receiver using GNU Radio and Rust :3

📷 Las Vegas, 2025-11-07

Show threadpistonminerNov 20

@destevez Incidentally after reversing it I also found this documentation page which appears quite useful. In particular the nested framing inside the space packets appears to match this page: https://max.rocketlabusa.com/docs#MAX/Command%20and%20Telemetry/Framing/Simple%20Frame.md

I think APID 740 also loosely matches what's here, though not exactly serialized like this:
https://max.rocketlabusa.com/docs#MAX/Source%20Code/File/struct-CFileDownloadMgr--SSetupTlm.md
https://max.rocketlabusa.com/docs#MAX/Source%20Code/File/struct-CFileDownloadMgr--SDataTlm.md

Perhaps some of the other structures ending in *Tlm might show up in some form in other APIDs, but that's just a wild guess...

Docs - ASI