Europa Clipper is a NASA mission that will study Europa, Jupiter’s icy moon, to investigate if it can support life, perhaps in hydrothermal vents in a global ocean under the ice crust. The mission launched on Monday from Cape Canaveral, after some days of delay due to Hurricane Milton. As happened with Psyche one year ago, the launch trajectory was such that the first pass over the Allen Telescope Array, in northern California, started only about 1.5 hours after launch. To put this in perspective, launch was at 2024-10-14T16:06 UTC, spacecraft separation at T+1:02:39, and my recording began at 17:33:24 UTC, with signal acquisition a couple minutes later as the spacecraft raised above the 16.8 deg elevation mask of the ATA antennas.
I used one of the ATA antennas to record the X-band telemetry signal for about 2 hours and 50 minutes, until the spacecraft set again due to Earth rotation. In this post I overview the recording and decode the telemetry with GNU Radio.
I recorded at 6.144 Msps IQ, but since the telemetry symbol rate was only 12 kbaud throughout all the recording, I have made files decimated to 96 ksps and published them in the dataset “Recording of Europa Clipper X-band telemetry with the Allen Telescope Array shortly after launch” in Zenodo. This decimation discards the sequential ranging tones, which were present during most of the observation, but it greatly reduces the file size.
Recording set up
For antenna tracking I used the ephemerides from HORIZONS. In other occasions I have computed my ephemerides directly from SPICE kernels, but the NAIF SPICE server didn’t have any kernels for the launch on 2024-10-14, while HORIZONS had a 21F31_MEGA_L241014_A300411_LP05_V7 kernel that turned out to be quite accurate. The following figure shows the antenna pointing and distance during the observation.
I used a single antenna, 1a, and recorded data in dual linear polarization IQ data at 6.144 Msps using a USRP N321.
Waterfall analysis
The following plot is a waterfall of the X polarization recording. The signal becomes very strong a few minutes after the beginning of the recording, as the elevation raises over the 16.8 deg mask and the dish begins tracking. Shortly after, sequential ranging tones begin. These are maintained throughout most of the observation. Around 19:30 UTC we see a signal drop. Shortly after 19:40 there is an uplink sweep, seen by a wavy shape on the downlink frequency. The signal almost disappears around 20:00 UTC. This is likely due to the spacecraft thermal roll (rotisserie mode), which sometimes points the low gain antennas away from Earth. Finally the signal reappears and then disappears as the spacecraft sets below 16.8 deg elevation.
A zoom to the telemetry carrier shows the Doppler more clearly, as well as some frequency jumps.
At 18:49:52 UTC there is an artifact lasting a few seconds. Even the noise floor level drops significantly, so I think that the cause is some very strong out-of-band interference that is saturating the receiver. This event can be seen as a dark line in the two waterfalls above.
At 19:29:30 UTC the transmitter stops and then it starts again 19 seconds later. When the transmitter starts we can see a brief frequency glitch (likely the free-running PLL locking). The transmitter starts outputting a 101010 sequence that causes spectral lines at 6 kHz from the carrier for a few seconds before it begins modulating frames. Shortly after, there are two frequency jumps, which I think correspond to a groundstation lock and unlock, and then the uplink captures and follows an uplink sweep.
Modulation and coding
The modulation is 12 kbaud PCM/PM/NRZ. This means that the telemetry is modulated phase-modulated on the RF carrier, leaving a residual carrier. Using no telemetry subcarrier is somewhat unusual for such a relatively low symbol rate. A subcarrier puts the telemetry power away from the residual carrier, so that it doesn’t interfere with the receiver PLL.
The coding is CCSDS r=1/6 Turbo with 1115 byte frames. This is the most sensitive FEC offered by CCSDS, so there are no surprises here. This modulation and coding choice is quite reasonable for a low-rate/safe-mode telemetry beacon. It is the same that Psyche used when it launched. AMSAT-DL reported that the modulation was switched to a much higher baudrate at around 22:30 UTC.
GNU Radio decoder
The GNU Radio decoder I have used is quite typical for this modulation and coding. The flowgraph is shown here.
For best results with the low symbol rate PCM/PM/NRZ modulation, I have used a PLL bandwidth of 10 Hz. With larger bandwidths there is too much interference from the telemetry modulation. Since the PLL bandwidth is narrow and there is substantial Doppler drift at the beginning of the recording, I have used the gr-satellites Doppler correction block to compensate for Doppler. I have computed the Doppler file using a horizons_doppler_correction.py script in the following way.
horizons_doppler_correction.py --carrier-frequency 8424.3 \
--spacecraft "Europa Clipper" \
--start-epoch 2024-10-14T17:35:00 --duration 10800 \
--time-step 1 --observatory "Hat Creek" \
--add-offset=196e3 \
--output-file europa_clipper_doppler.txt --plot
The Auto-polarization block (which is now included in gr-satellites) is used to automatically determine the polarization of the signal and combine the two linear polarizations to optimize the SNR. After a straightforward PCM/PM/NRZ demodulator, the Turbo decoder block from gr-dslwp is used. The CRC-16 of the telemetry frames is checked, and correct frames are written to a binary file.
The GUI of the GNU Radio flowgraph while running on the recording is shown here. Most of the time the SNR is excellent.
AOS frames
The frames transmitted by Europa Clipper are CCSDS AOS frames. There is no Operational Control Field. In this recording, virtual channels 32 and 63 are in use. Both of them carry CCSDS Space Packets using M_PDU.
Virtual channel 32 transmits real time telemetry. APIDs 5-8, 10-13 and 2047 (the idle APID) are used. All the non-idle APIDs have a 6-byte secondary header that contains a timestamp. I will do a more detailed analysis of these Space Packets in a future post.
Frame loss according to the virtual channel frame count for virtual channel 32 is zero throughout the recording, except in the moments when the signal jumps in frequency or fades out.
Virtual channel 63 is the only-idle-data virtual channel. It contains Space Packets from APID 2047. A single packet is used to fill the whole AOS frame, but for some reason the first header pointer is not zero. There are only two frames from virtual channel 63 in this recording, and their first header pointer is 5 and 1. The payload of each APID 2047 packet contains the following message in ASCII (or the beginning of it, if the packet is shorter).
N.Alderson M.Aleem K.Altimus R.Banduric A.Black I.Brault J.Brown B.Campuzano B.Chen S.Cheng S.Chou N.Chow T.Clark N.Colindres D.Cummings J.Davis A.Diaz-Calderon A.Dobrev P.Doronila B.Duckett J.Fernandez D.Gaines G.Gandhi R.Gio K.Gov D.Hahn L.Hall S.Harris J.Hennawy K.Jones M.Jordan R.Joshi D.Karlsson C.Kellerman D.Kessler S.Khan J.Kochocki R.Largaespada L.Manglapus N.Markovitch S.Mikaelian L.Miller B.Morin N.Nguyen A.Niessner C.Oda C.Parker P.Partikian J.Pelayo I.Peng S.Reddy L.Reder K.Reinholtz M.Rodriguez-Chen K.Roffo P.Romano K.Rosario M.Sandoval T.Seto-Mook C.Skeggs A.Smith D.Tran M.Tuszynski I.Uchenik M.Wade E.Wang C.Williams V.Woo P.Dunn S.Hornbeck S.Lai A.Moncada T.Neilson M.Thielman J.Walker T.Wysocky J.Lam G.Singh C.Ballard J.Berman J.Bowles-Martinez C.Brennan B.Cantos J.Castet E.Dodd M.Jackson A.Kerzhner R.Kinnett G.Lee R.Morillo M.Salami B.Smith M.Soriano C.Swan B.Ferdowsi D.Hecox A.Holloway C.Hua C.Jones D.Kou J.Lai D.Leang S.Scandore A.StAmand V.Verma K.Weiss and many others, including those whose support has been invaluable "we, too, are made of water" -- A.Limon
Generally speaking, there are many similarities between the telemetry of Europa Clipper and that of Psyche. This makes sense, because the two spacecraft are the latest interplanetary NASA missions.
Code and data
The recording used in this post is in the dataset “Recording of Europa Clipper X-band telemetry with the Allen Telescope Array shortly after launch“. The Jupyter notebooks for the antenna ephemeris and the waterfall plots can be found in this repository. The GNU Radio decoder flowgraph, output file and Jupyter notebook with the frame analysis are in this repository.
Re: “This is the most sensitive FEC offered by CCSDS,”
I think the coding people refer to “power” rather than “sensitive”, but I’m not one of them. And I think the performance of the Turbo 1/6 is that it’s a rate 1/6 code, so there’s a lot of extra bits being transmitted. I seem to recall that for equivalent code rates, LDPC and Turbo perform about the same.
A cool part of Turbo codes is that the original bits are in the transmitted signal (unlike convolutional codes), so if you’ve got good SNR, you can recover the message without having to actually run a decoder. (handy in the lab).
Being recently immersed in things CCSDS: It’s not that CCSDS is a supplier or regulatory agency that offers products or mandates certain options. They just publish standards, and missions are free to use CCSDS standards or not. Following the standard makes interoperability easier.
NASA as an institutional policy prefers following standards, although it’s not unheard of to fly something that isn’t yet a standard. Perhaps because the standard is under development, or it’s just one of the required two implementations to be a blue book.
Thanks for the comment! The sentence you quote is quite informal/imprecise and could have been written much better. Rather than “sensitive”, I should have said that it has a lower Eb/N0 decoding threshold. Measuring in terms of Eb/N0 is fair regarding different coding rates. The underlying assumption in this comparison is that the transmitter power and net data rate is held constant, so a 1/6 code sends a lot of extra bits, but each of those bits has less energy. In any case, lower rate codes generally have a lower Eb/N0 threshold because of Shannon’s capacity (they use more bandwidth) and because of other factors having to do with code design.
By “offered”, I probably had in mind “the set of configuration options that the CCSDS standard offers” (for those willing to stay within the standard, that is). But as an implementer of communication systems, I should also say that CCSDS describes the recommended standards with excellent technical documentation (specially in the Green Books), and some of the options they have (e.g., Turbo and LDPC codes) are rather good. So when implementing a new system, even if compatibility is not a concern, choosing CCSDS instead of rolling your own from scratch can be a good option, because a lot of the design work has already been done for you. In that sense, I can also say the standard “offers”.