In my previous post I wrote about the protocols used by Blockstream Satellite. This was motivated by a challenge in GRCon22’s CTF. In that challenge, muad’dib sent the flag as a Blockstream API message and recorded the Blockstream Satellite DVB-S2 downlink as the message was broadcast. The recording was used as the IQ file for the challenge.
In my post, I gave a look at how all the protocol stack for the Blockstream API works: DVB-S2, MPE, IPv4, UDP, plus a custom protocol that supports fragmentation and application-level FEC. However, I didn’t give any details about how the protocols used to broadcast the Bitcoin blockchain work. This runs on another UDP port, independently of the Blockstream API. At that time I didn’t understand much about it, even though during the CTF I was trying to search for the flag in a Bitcoin transaction and looking at the source code of bitcoinsatellite to try to figure out how it worked.
After my previous post, Igor Freirecommented some details of the FEC used in bitcoinsatellite. This is quite interesting by itself. Two FEC libraries by Chris Taylor are used: the Wirehair O(N) fountain code for larger blocks, and the CM256 MDS code based on Cauchy matrices over GF(256) (this is very similar to Reed-Solomon used as erasure coding). This motivated me to continue studying how all this works.
Now I have been able decode the Bitcoin transactions in the CTF recording. These don’t use any FEC, since transactions are small. I believe that there aren’t any blocks fully contained in the 35 second recording, so to see how the FEC codes work (which could be quite interesting) I would need a longer recording.
In this post I’ll show how to decode the Bitcoin transaction in Blockstream Satellite. The materials can be found in this repository.
A heighliner just passed through “folded space” and it has sent a secret message to the remaining members of House Atreides on the surface of Arrakis. The communication protocol was historically used for sending visual propaganda films and archival files, recently however, Duke Leto had his engineering guild repurpose the transmission unit for financial transactions. It’s the perfect place for a covert message, the Harkonnens would never think to look there… The original transmission was on Frequency 12.0164GHz. Our groundstation receiver downconverted to 1.2664GHz.
Heighliner challenge description
I didn’t manage to solve this challenge, mainly because I was looking in the wrong place. I was focused on looking at the Bitcoin blockchain chunks, but the flag was in a Blockstream Satellite API message, and I wasn’t aware of the existence of API messages back then. After the CTF ended, a few of us were discussing this challenge in the chat. None of us really understood all the details about how the Blockstream Satellite system works. Since the intended way of solving the challenge was setting up and running the Blockstream Satellite receiver tools, an in-depth understanding wasn’t really necessary.
I have some interest in satellite filecasting systems since I reverse-engineered Outernet back in 2016, so I’ve been taking some time after the CTF to look at the details of how Blockstream Satellite works. While attempting to solve the challenge, I found that detailed enough documentation wasn’t available. There is some high-level documentation, but for the details you need to go to the source code (which is a typical situation).
In this post I describe the details of how Blockstream Satellite works, using the recording from the CTF challenge as an example. I will mainly focus on the Blockstream Satellite API, since I haven’t been able to understand all the details of the Bitcoin blockchain FEC blocks.
I have spent a great week attending GRCon22 remotely. Besides trying to follow all the talks as usual, I have been participating in the Capture The Flag. I had sent a few challenges for the CTF, and I wanted to have some fun and see what challenges other people had sent. I ended up in 3rd position. In this post I’ll give a walkthrough of the challenges I submitted, and of my solution to some of the other challenges. The material I am presenting here is now in the grcon22-ctf Github repository.
Happy New Year! To celebrate, I have put together a list of RF recordings. Over the last few years, and specially since the start of the collaboration between GNU Radio and SETI Institute, I have been publishing a number of RF recordings in Zenodo. The search function of Zenodo is not very good, and I thought that readers of this blog would find useful to have a list of all the recordings I have published. The list of recordings can be accessed here and in the website menu, under “Publications“.
I have also published an excerpt of the recording of James Webb Space Telescope that I did on December 26. This is just the first 25 minutes of the recording, so that both polarizations fit into maximum 50 GB of a Zenodo dataset. The sample rate is still 3.84 Msps, so the sequential ranging tones are present in these files. The dataset is called “James Webb Space Telescope S-band recording with Allen Telescope Array (wideband excerpt)“. In some days I will also publish a decimated version (containing the telemetry but not the ranging tones) of the full recording.
I managed to solve this challenge shortly after it was published, and sent Jean-Michel a Jupyter notebook explaining my solution. Jean-Michel liked this approach and invited me to present my solution today at the conference. This presentation can be watched in the recording of the conference livestream.
I have now published a repository with all the material of my solution. Thanks to Jean-Michel for putting together this interesting and enjoyable challenge and to NI for providing a prize to make the challenge more attractive.
Yesterday we had a strong storm in Madrid at around 16:30 UTC. The storm was rather short but intense. Seeing the heavy rain, it occurred to me that I might be able to receive the 10 GHz beacon ED4YAE at Alto del León using my QO-100 groundstation (without moving the antenna).
The 10 GHz beacon is 39.4 km away and the direct path to my station is obstructed by some hill in the middle, as shown in the link profile.
In the countryside just outside town it is possible to receive the beacon, probably because it diffracts on the hills. However, it is impossible for me to receive it directly from home, as there are too many tall buildings in the way.
In fact, when I fired up my receiver as the storm raged, I was able to see the beacon signal, with a huge Doppler spread of some 700 Hz (20 m/s). The CW ID of the beacon was easy to copy.
Then I started recording the signal. As the rain got weaker, it started disappearing, until it faded away completely. This post is a short analysis of the scatter geometry and the recording.
Yesterday, May 14th, at around 23:18 UTC the Tianwen-1 rover Zhurong safely landed on the Utopia Planitia region of Mars. To follow this event, AMSAT-DL made a 7 hour livestream of the orbiter signals as received by the 20m antenna in Bochum observatory. In this livestream we could see the signal losses caused by the manoeuvres of the deorbit burn and collision avoidance burn. Analysis of the telemetry decoded at Bochum shows more details about these manoeuvres. This post is a detailed report of the landing.
Back in 2019, I took advantage of the autumn sun outage season of Es’hail 2 to make some observations as the sun passed in front of the fixed 1.2 metre offset dish I have to receive the QO-100 transponders. Using the data from those observations, I estimated the gain of the dish and the system noise. A few weeks ago, I have repeated this kind of measurements in the spring sun outage season this year. This post is a summary of the results.
Today at 9:00 UTC Tianwen-1 made its plane change manoeuvre, as reported by Xinhua. Yesterday I showed my planning for this manoeuvre. Shortly after the spacecraft returned to the high gain antenna after the manoeuvre, the Bochum 20m antenna operated by AMSAT-DL received state vectors with the new trajectory. These state vectors allow us to calculate the timestamp of the burn and the delta-V vector, as I have done in other occasions. It is convenient to remark that the state vectors that we are seeing right now are probably a prediction. In the next few days we will see updates in the trajectory as the Chinese DSN measures the effects of the actual burn and updates the onboard ephemerides.
Today, the Chinese media published a short piece of news stating that tomorrow, 2021-02-15, Tiawen-1 will make make a plane change to a polar orbit. The post is accompanied by an short video, which includes an animation depicting the manoeuvre. A screenshot of the video is shown below. As the spacecraft arrives to apoapsis, it effects a plane change into an ascending polar orbit.
This is a good moment to review the maths behind a plane change manoeuvre and compute what the manoeuvre will look like.