BlueWalker 3 is a satellite built by AST SpaceMobile that was launched in 2022-09-11. It is as a prototype mission that will try to communicate from low Earth orbit with unmodified cellphones on ground using a large 64 m² unfoldable phased array antenna. It has received some criticism because of concerns of the satellite being too bright due to the large antenna (impacting astronomy observations) and potentially causing RF interference to radioastronomy and other services, since the cellular bands it will use are normally used only in terrestrial applications.
It also received criticism when shortly after launch, amateur radio operators noticed that the satellite was transmitting packets on 437.500 MHz, in the UHF amateur satellite band. The mission of this satellite is not compatible with the amateur radio service and it hasn’t received IARU coordination. There were some arguments on Twitter about whether BlueWalker 3 actually had the proper experimental license from the FCC to do this or not, and people posted ITU SNL filings and FCC applications. I didn’t track all of this in detail, so I don’t have a well informed opinion about whether BlueWalker 3 is following the regulations correctly.
A month ago, I looked at the UHF packets and checked that BlueWalker 3 used exactly the same modulation and coding as Light-1, which is a 3U cubesat from United Arab Emirates (this was first discovered by Tetsurou Satou JA0CAW). The framing contains the typical elements of the built-in packet handler of low cost FSK chips such as the Texas Instruments CC11xx family. Scott Tilley noticed some details that seem to explain this connection: Light-1 was built by NanoAvionics, which apparently has collaborated with AST SpaceMobile in the BlueWalker 3 mission. Therefore, it seems that the satellite bus used by BlueWalker 3 is that of a typical cubesat.
BlueWalker 3 also transmits in S-band, at a frequency of 2245 MHz. Scott Tilley has been doing some observations of this signal and sharing some recordings. Aang254 has been analysing the signal and remarks that it’s mostly idle data. In this post I’ll do an analysis of the BlueWalker 3 S-band signal using two recordings made by Scott.
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.
STEREO-A is a solar observation satellite in a heliocentric orbit with a period of 346 days (slightly less than the Earth). It was launched in 2006 together with STEREO-B, which failed 2016. STEREO-A is still operational and producing science data. Whenever the spacecraft is not being tracked by the DSN, its X-band downlink at 8443.530 MHz transmits the so-called space weather beacon. This is a low data rate (~633 bits per second) downlink that contains a summary of the instruments data and that can be received by smaller stations (such as AMSAT-DL’s 20 metre antenna in Bochum, which is one of the stations used to track STEREO-A).
Yesterday, Wei Mingchuan BG2BHC shared some recordings of STEREO-A done with a 13 metre antenna in Harbin Institute of Technology. A large portion of these recordings contains the space weather beacon signal, but there is another part where the transmission first goes carrier only and then transmits wideband data (although the SNR and the recording bandwidth are not enough to work with this signal). Apparently, STEREO-A was being tracked by DSS-35 in Canberra between 7:25 and 10:30 UTC, more or less at the same time that Wei was recording.
In this post I analyse the space weather beacon signal in these recordings.
GUPPI stands for Green Bank Ultimate Pulsar Processing Instrument. The GUPPI raw file format, which was originally used by this instrument for pulsar observations, is now used in many telescopes for radio astronomy and SETI. For instance Breakthrough Listen uses the GUPPI format as part of the processing pipeline, as described in this paper. The Breakthrough Listen blimpy tools work with GUPPI files or with filterbank files (basically, waterfalls) that have been produced from a GUPPI file using rawspec.
I think that GNU Radio can be a very useful tool for SETI and radio astronomy, as evidenced by the partnership of GNU Radio and SETI Institute. However, the set of tools used in the GNU Radio ecosystem (and by the wider SDR community) and the tools used traditionally by the SETI community are quite different, and even the file formats and some key concepts are unalike. Therefore, interfacing these tools is not trivial.
During this summer I have been teaching some GNU Radio lessons to the BSRC REU students. As part of these sessions, I made gr-guppi, a GNU Radio out-of-tree module that can write GUPPI files. I thought this could be potentially useful to the students, and it might be a first step in increasing the compatibility between GNU Radio and the SETI tools. (The materials for the sessions of this year are in this repository, and the materials for 2021 are here; these may be useful to someone even without the context of the workshop-like sessions for which they were created).
In this post I will show how gr-guppi works and what are the key concepts for GUPPI files, as these files store the output of a polyphase filterbank, which many people from the GNU Radio community might not be very familiar with. The goal of the post is to generate a simulated technosignature in GNU Radio (a CW carrier drifting in frequency) and then detect it using turboSETI, which is a tool for detecting narrowband signals with a Doppler drift.
Before going on, it is convenient to mention that an alternative to this approach is using gr-turboseti, which wraps up turboSETI as a GNU Radio block. This was Yiwei Chai‘s REU project at the ATA in 2021.
Danuri, also known as KPLO (Korean Pathfinder Lunar Orbiter), is South Korea’s first mission to the Moon. This satellite will orbit the Moon in a 100 km altitude polar orbit. Danuri was launched on 2022-08-04 by a Falcon 9 rocket from Cape Canaveral into a ballistic lunar transfer orbit. It transmits telemetry in S-band at 2260.8 MHz. Additionally, it has a high speed downlink at at 8475 MHz for science data. The S-band downlink uses LHCP (left-handed circular polarization), which is a somewhat unusual choice, as most satellites use RHCP.
Yesterday, on 2022-08-05, the CAMRAS PI9CAM team used the 25 metre Dwingeloo radiotelescope to record the S-band downlink from Danuri. It is unclear if they used the correct polarization, but nevertheless the SNR of the signal is very good. The recordings are published in SigMF format in CAMRAS data repository. In this post I analyse the recordings and show how to decode them with GNU Radio.
On July 13, the Vega-C maiden flight delivered the LARES-2 passive laser reflector satellite and the following six cubesats to a 5900 km MEO orbit: AstroBio Cubesat, Greencube, ALPHA, Trisat-R, MTCube-2, and CELESTA. This is the first time that cubesats have been put in a MEO orbit (see slide 8 in this presentation). The six cubesats are very similar to those launched in LEO orbits, and use the 435 MHz amateur satellite band for their telemetry downlink (although ALPHA and Trisat-R have been declined IARU coordination, since IARU considers that these missions do not meet the definition of the amateur satellite service).
Communications from this MEO orbit are challenging for small satellites because the slant range compared to a 500 km LEO orbit is about 10 times larger at the closest point of the orbit and 4 times larger near the horizon, giving path losses which are 20 to 12 dB higher than in LEO.
I wanted to try to observe these satellites with my small station: a 7 element UHF yagi from Arrow antennas in a noisy urban location. The nice thing about this MEO orbit is that the passes last some 50 minutes, instead of the 10 to 12 minutes of a LEO pass. This means that I could set the antenna on a tripod and move it infrequently.
As part of the observation, I wanted to perform an absolute power calibration of my SDR (a USRP B205mini) in order to be able to measure the noise power at my location and also the power of the satellite signals power, if I was able to detect them.
Satellite RF signals are shifted in frequency proportionally to the line-of-sight velocity between the satellite and groundstation, due to the Doppler effect. The Doppler frequency depends on time, on the location of the groundstation, and on the orbit of the satellite, as well as on the carrier frequency. In satellite communications, it is common to correct for the Doppler present in the downlink signals before processing them. It is also common to correct for the uplink Doppler before transmitting an uplink signal, so that the satellite receiver sees a constant frequency.
For Earth satellites, these kinds of corrections can be done in GNU Radio using the gr-gpredict-doppler out-of-tree module and Gpredict (see this old post). In this method, Gpredict calculates the current Doppler frequency and sends it to gr-gpredict-doppler, which updates a variable in the GNU Radio flowgraph that controls the Doppler correction (for instance by changing the frequency of a Frequency Xlating FIR Filter or Signal Source).
I’m more interested in non Earth orbiting satellites, for which Gpredict, which uses TLEs, doesn’t work. I want to perform Doppler correction using data from NASA HORIZONS or computed with GMAT. To do this, I have added a new Doppler Correction C++ block to gr-satellites. This block reads a text file that lists Doppler frequency versus time, and uses that to perform the Doppler correction. In this post, I describe how the block works.
In my previous post I showed a GNU Radio demodulator for the QO-100 multimedia beacon, which AMSAT-DL has recently started to broadcast through the QO-100 NB transponder, using a downlink frequency of 10489.995 MHz. This demodulator flowgraph could receive and save to disk the files transmitted by the beacon using the file receiver from gr-satellites. However, the performance was not so good, because it had a couple of ad-hoc Python blocks. Also, the real-time streaming data (which uses WebSockets) was not handled.
I have continued working in the decoder and solved these problems. Now we have a decoder with good performance that uses new C++ blocks that I have added to gr-satellites, and the streaming data is supported. I think that the only feature that isn’t supported yet is displaying the AMSAT bulletins in the
qo100info.html web page (but the bulletins are received and saved to disk).
I have added the decoder and related tools to the examples folder of gr-satellites, so that other people can set this up more easily. In this post I summarise this work.
Last weekend, AMSAT-DL started some test transmissions of a high-speed multimedia beacon through the QO-100 NB transponder. The beacon uses the high-speed modem by Kurt Moraw DJ0ABR. It is called “high-speed” because the idea is to fit several kbps of data within the typical 2.7 kHz bandwidth of an SSB channel. The modem waveform is 2.4 kbaud 8APSK with Reed-Solomon (255, 223) frames. The net data rate (taking into account FEC and syncword overhead) is about 6.2 kbps.
I had never worked with this modem before, even though it served me as motivation for my 32APSK modem (still a work in progress). With a 24/7 continuous transmission on QO-100, now it was the perfect time to play with the modem, so I quickly put something together in GNU Radio. In this post I explain how my prototype decoder works and what remains to be improved.
The James Webb Space Telescope probably needs no introduction, since it is perhaps the most important and well-known mission of the last years. It was launched on Christmas day from Kourou, French Guiana, into a direct transfer orbit to the Sun-Earth L2 Lagrange point. JWST uses S-band at 2270.5 MHz to transmit telemetry. The science data will be transmitted in K-band at 25.9 GHz, with a rate of up to 28 Mbps.
After launch, the first groundstation to pick the S-band signal from JWST was the 10 m antenna from the Italian Space Agency in Malindi, Kenya. This groundstation commanded the telemetry rate to increase from 1 kbps to 4 kbps. After this, the spacecraft’s footprint continued moving to the east, and it was tracked for a few hours by the DSN in Canberra. One of the things that Canberra did was to increase the telemetry rate to 40 kbps, which apparently is the maximum to be used in the mission.
As JWST moved away from Earth, its footprint started moving west. After Canberra, the spacecraft was tracked by Madrid. Edgar Kaiser DF2MZ, Iban Cardona EB3FRN and other amateur observers in Europe received the S-band telemetry signal. When Iban started receiving the signal, it was again using 4 kbps, but some time after, Madrid switched it to 40 kbps.
At 00:50 UTC on December 26, the spacecraft made its first correction burn, which lasted an impressive 65 minutes. Edgar caught this manoeuvre in the Doppler track.
Later on, between 7:30 and 11:30 UTC, I have been receiving the signal with one of the 6.1 metre dishes at Allen Telescope Array. The telemetry rate was 40 kbps and the spacecraft was presumably in lock with Goldstone, though it didn’t appear in DSN now. I will publish the recording in Zenodo as usual, but since the files are rather large I will probably reduce the sample rate, so publishing the files will take some time.
In the rest of this post I give a description of the telemetry of JWST and do a first look at the telemetry data.